Epic Web Conf '24 Speakers

Dan Farrelly

CTO + Co-founder at Inngest

Watch Talk


  • Thursday, 1:30 PM1:35 PM
    Improve performance and reliability of your API with events and background functions


Dan is the CTO and co-founder at Inngest.com, the easiest way to ship durable serverless functions. He previously was the CTO at Buffer.com for several years. He spends most of his free time restoring a 100 year old craftsman bungalow and getting into the outdoors.


share on twitter


Hello, everybody. I am excited to be joined by my friend, Dan. How are you doing, Dan? Great. How are you doing, Ken? Doing awesome. So, Dan, actually, this is the first time we're meeting, but I know people

that have worked for you or do work for you, and they speak highly of that experience. So yeah, I'm excited to get to know you a little bit. I want folks who are potentially going to come to the conference, or at least watch online, to get to know you a little bit before as well. So can you give us a little intro to yourself?

Yeah, sure. Thanks. Yeah, so my name is Dan Farrelly. I am the CTO and a co-founder at the company called Jest. Previously, I was the CTO at Buffer.com, and previously, I worked up from a front-end engineer, full-stack engineer, to become the CTO of that company. And across

my career, I've started in the front-end and then worked across the full-stack, gotten to infra and DevOps, and I've kind of worked in all the different areas. So I really enjoy all the aspects of building software, and everything's been in the cloud since day one.

So it's just where I feel comfortable, and I think it's just a lot of fun problems every single day that you get to solve. And I guess interacting and learning from the community has been really big for me for the last 10 years, or it's a little bit long in that now.

But yeah, it's been fantastic. Wow, yeah. Time flies, and our interests change over time as well. And so bouncing around the whole stack is fun. Do you still find yourself doing front-end, back-end web stuff, or are you all infra now?

It's all across the board still, because we're a small team at Ingest, and we have all types of engineers, full-stack, front-end, and infra-heavy folks. And there's always new problems, right? As you're scaling your product or finding cracks in assumptions that you made at the

time that the scale changed in six months, it kind of pulls you in different areas, which is fantastic. It's fun. There's always new challenges. So I think we were just researching something with a database that we have that kind of has reached the scale that we feel

good about, and we need to separate it and have a plan. So we're all researching, comparing database options. And that's just like, that's fun. And yesterday, it was me dealing with some front-end stuff. So I love the variety. Maybe I'm a generalist. Yeah, that's fun. So I take it that it's very intentional that Ingest is trying to stay

small and not just grow to this massive, as far as the number of employees and everything. I always admire companies that try to maintain a reasonable size, because I think there's

a lot that you can do with fewer people. And as you grow, there are just new challenges that you have to face that don't involve the core offering that you provide. Would you say that's kind of your goals there?

Yeah, yeah. I think, of course, over time, it makes a lot of sense when you grow a team to bring in new talented folks. But I think, ideally, when your team is small, that is

sometimes so fun, because also you can touch and get context on what is going on. So you don't over-specialize and you can understand about the user and about what the problems are on different parts of the system, which I think also exposes you to the whole picture.

Because the reason why your app might be slow might be because of your database, or it might be because of this one service, or it might be because of how you're handling something in your API. And I think if you're heavily compartmentalized, you may not have exposure

to that. So I think that's when you're trying to move quickly and trying to solve things net new for a customer, I think it's amazing to stay small. And then just the communication overhead is also extremely small too. So it generally tends to, when you hire people in the beginning, to attract more generalist

folks. And as you get bigger, maybe some more specialization. But yeah, I think being intentional there is always key because I think, we've all heard it probably and worked in orgs where you hire a bunch more people and it doesn't solve problems, right? It maybe takes some

problems and makes them larger, just over a bigger scale. So I think it's really key to be intentional about how you're growing a team and get the input also of your team to feel back, to say like, all right, how should we grow this? And make sure that there's

stakeholders because that's, I think anyone who joins an early team wants to feel like they're part of something like they can contribute on different levels. So I totally agree. I think we had a relatively small team at Buffer. And I think the best thing that we tried to

do over the years there were improve the tooling and allow people to do more with having to worry about, I don't know, we didn't have a gigantic infrastructure team. We had a very lean team that was very good, but we streamlined and automated as much as possible. So adopted

DevOps principles very early to enable product engineers to just ship, not have to worry about anything. So I think that's just some intentions about how you need to grow. And I think at this stage, it's blast. And I like to stay small as much as we can.

Yeah. Yeah. Well, that's cool. And so because you're a small team, I'm guessing that you find yourself even as the CTO, you find yourself doing quite a bit of development on the platform as well. Is that right?

Yeah. Yeah. Jumping in here and there. I find myself in the last year we've grown from maybe like three or four people to just over 10. And we're going north of that a little bit, you know, little by little. And I don't have that. I used to be writing a lot more code. I don't

have the time for it right now. It's too many, you know, jumping around. So I try to unblock people mostly. I end up trying to do the things that people don't want to do. So it's like, you know, it's this army knife type thing. And I think that that's what, you know, you end up having to be to not allow your team to like really do what they're great at and really

motivated to do the hard stuff that they can build out and own long term. So, yeah, it's still still a fair bit of coding. And yeah, the stack always changes. You always get to learn new things. So you got to stay sharp. I think that's one thing that like I when I was CTO

buffer, I'd like maybe didn't code as much. And then coming back, coming and starting ingest was like it was, you know, coding and building products full time again. And that was just like very fulfilling to me. I kind of forgot how much I missed being hands on. Yeah. Yeah. Creating and building stuff. Yeah. Very cool. So at the conference, you're going

to be speaking. Do you want to give us a little preview of some of the things that you're thinking about, including in your talk? Yeah. Yeah. So I think, you know, I kind of hinted at it wasn't really intentional. It just kind of came out that way before. But about how, you know. APIs can become slow or bloated

on over time, they often like start really small and nice and clean. And then you're just application gets more complex. Right. You add new database, database models. Maybe now you're you're writing to multiple tables in an endpoint. Your application starts to get a little bit slower. Maybe there's a there's transactions that need to happen. Maybe there's

third party services that you need to communicate. And what originally started to be so like small and beautiful and simple ends up sometimes just getting more complex over time, maybe more bloated. And like that's natural. That's totally natural. There's nothing wrong with that. Every everything I think goes through that. That's that's growth and expanding and

making your application more powerful. Yeah, that's the real world. Yeah, that's just what it is. Right. And it's I think what's what's what gets hard over time is like, how do you approach those problems? How do you improve an API that's been around for

eight years? Right. Even four years. And how do we make this faster? But we don't reduce any reliability for our users because, you know, they get longer. The APIs can get slower. Your application might get a little bit slower. The user experience gets slower. It's like everyone starts to feel it. And sometimes they're those things you're like, I don't want to touch that

one. So really, really. And like I can I know a lot of examples. I'm sure you can. I'm sure other people are listening or like I know I have that function. That's 500 lines and no one touches it. So, you know, it's a short talk, but I just kind of wanted to talk about some

basically like fundamental patterns and I think considerations for approaching and improving those those types of applications, those those challenges over time, because, you know, it's like any, you know, sometimes those core functions or those core endpoints are the most

important part of your entire system. And so, you know, it's key to be able to maintain and improve that. Right. It's like taking care of your own home or something that you know, your hobby that you like, you know, it's maintaining that. So I'd like to talk a little bit about

that, how to like break out of some of those those those systems and improve things with the use of background functions and events and different type of ways to ensure reliability when you do that. So, cool. It's some fun stuff. It's a topic that I'm passionate about.

Well, yeah, clearly, I'm looking forward to hearing that talk. Now, while we're at the conference, we're going to have plenty of people watching online and people are going to be there and they're going to want to talk to you, Dan. So what are you hoping that people come and talk with you about and what are you hoping to be able to talk with others about?

Yeah, yeah. You know, you know, I'll be totally selfishly, you know, it's I'll be honest, it's adding just we're building a developer tool. So I've just been it's the previously I built consumer like B2B tools, but for marketing teams. So I'm just like so excited building Ingest and

talking to developers every day and learning what their problems are and what are their challenges and how do they think about how do they approach the problems that they want to solve? Because I think that's just, you know, it's for me just personally has always been interesting, you know, going to meetups, local meetups and conferences before in the day, like

back in New York and I've been in SF and now I live in Detroit and it's amazing interacting with folks. And like, that's really like what I'm all looking for is just like hearing what people are working on and sharing stories and ideas and stuff. Because I think that's like in when I've been to all those events over the span of my career, that's where I've had like light bulb

moments and leveled up and then like, oh my goodness, I did that just clicked, you know, like the first time I saw someone do unit testing, it was a meetup and I was like, what is this going to be about? I was like, oh my god, and it was very early on in my career to help so much. So I think

that's just like what I it fuels me also for the next, you know, few months to go out and be inspired. So like that's that's I'm excited to chat with other folks about that. And hopefully they can inspire me, hopefully I can inspire them and just build off that. So I think that's

what's beautiful about the like, software community in general and how it's always been. Yeah, yeah. That's the sort of connection that you can only really have in person, where you're, you know, looking at each other face to face and having these conversations. And I've had lots of

experiences where you develop that relationship. And now, like you may have known each other online before, but now that you've like talked to that person, your conversations online are just deeper, as well. So I'm looking forward to meeting you in person for that. And yeah, super happy to

have you on that stage in April. So looking forward to seeing everybody there. And thanks so much for giving us your time today, Dan. Yeah, of course. Excited for the conference. And thanks, Kent. Okay, bye, everyone.