Tony Holdstock-Brown, CEO of Inngest: orchestration, traction and not using LinkedIn

And then you get it out and then the journey of iterating is a is a different kind of fun. And that different kind of fun can be both really good and really bad because like you're talking about with the autonomy, the absolute, honestly, lack of obvious direction to a degree at times. It can be it can be particularly challenging. Like when you do GTM or whatnot, there's so many different directions you can go in and knowing which one to do can be particularly challenging at times. And so I feel like you just have to be comfortable with throwing stuff on the wall and seeing what sticks and that is really really hard as a solo founder.

Really hard as a solo founder. I I I understand where you're at. I don't know how people do the whole solo founding thing or like full respect for them.

I am. But like the profile was vacant just because there's so much to do in the company to company build. But then my co founders and other people in the team do that more than me, which is okay. And that helps me focus. But even then, you know, with the context switching in the company, there's so much stuff that that crops up and there's so much stuff that demands attention. It can be really really tough. And I I've always I bought the book so I could get more strategies on how to fix that.

And so technically it's right that you should build an audience and try to make that work. And people have talked about this for a long time, it's very understood. Personally, I don't do that, my co founder Dan does and that's great. We also rely on other people that have done audience building to help talk about us, which isn't It is good in that it's short term gains but it's not long term owning your own distribution, But it's still a thing that gets your name out there and bypasses that you need to build your own audience over the long term. And in fact, to a degree, might say it could be better arguably because when you build your own audience, the chances are the audience that you're speaking to understands you and the product that you built.

And if you go to people that have built their own audiences and share with them, the overlap will be maybe some, but there'll be a lot of net new. And so we just go out and find people that have got their own audiences that are talking about things and see if they're interested in partnering. And that works and is pretty good in terms of the social media game. I think like in terms of just general awareness for DevTools, there's there's so so much to talk about. Yeah.

I was just like, dude. Have you read this book Traction by the DuckDuck co founders? No. Dude, fantastic book.

Cool. Take another two weeks and do another two week sprint. And he does like I think it's like 19 traction channels. Some of them are YouTube sponsorship emails, emails with your own audience, cold emails which is just I've never done it.

I I guess like yeah. We can break down some of the stuff that we've done to try and and and grow what we've talked about. But it's social media is like just everywhere. Yeah. Everywhere.

Yeah. And yeah. Like, you know, I I don't I don't write the tweets, I don't do the thing. But I think over time, the marketing team will try and convince me to. So you know, Endo will push you into that and be like, here's something I wrote for you, give me the login.

These things are hard to build, and you could get stuck spending all your time doing that instead of actually making a great dev tool. That's why WorkOS exists. They help you with all of those enterprise features, and they're trusted by OpenAI, Vercel, and Perplexity. And if you use them for user management, you get your first million, yes, million, monthly active users for free. I honestly don't know any dev tools that have a million monthly active users apart from GitHub, maybe.

So that'll get you pretty far. Here's what Kyle from Depot has to say about WorkOS.

Like, it's no problem. So it really allows smaller startups to essentially offer, like, that enterprise feature, without a huge engineering investment behind it. Like, it's literally we can just use a tool behind the scenes, and our life is exponentially easier.

I mean, I feel like it I mean, if it's genuine, surely it is a good thing. Right? Like, inferior, it's a

And when you're talking to investors, you do the same thing. And the really fun conversations that you have with investors are partnerships. It's like when you talk about the problem that you're solving, what's changing in the world, why it matters, why now? I think that's like quite inspiring for people overall because like, especially when you hear somebody's thought process that's similar, maybe slightly different, they bring up interesting points and it helps you sort of become either more aware or think differently about what might be happening in the world. I do think it's good in limited Yeah.

In limited doses. Yeah. Yeah. Yeah. Yeah. It's pretty good. Then you can get sort of carried away in your own world. Yeah. Yeah. Which is and and like honestly, the execution of the thing that you're doing is so so so very important that I think like in my mind at least, everything ties back to the execution of the product that you're building and the problem that you're solving and how you can make that work pretty well. So

You and honestly, I feel like you should have strong conviction strong opinions in the area in which you work for sure. And if you don't, I would have some internal questions about working in that space in general. And if you do have strong opinions on that particular area, should have some sort of medium and long term plan and understanding of what's happening and what's changing and have the ability to actually talk about it even if it's controversial and if it's controversial, that's probably a good thing as well. Then like I'm not gonna sit here and talk about, I don't know, finance. You know, I'm not gonna talk about anything to do with Bitcoin or any of that stuff anymore.

Like just yeah. Don't yeah.

But before that, you were talking about, like, the sprints in the two weeks. And I think I think people will be very interested in hearing like if you've tried that, if there's any things that you've learned in in doing that, maybe like any specific examples.

They might not work over time, not because your product changes or the audience changes, but because you exist. You you sort of not exist, you you sort of exhaust the entire audience that's available in that particular attraction channel. But specifically for us, we sat down and we took a look at a bunch of attraction channels that might be relevant. There's the whole content marketing stuff. There's the whole content plays, education plays to deliver education.

YouTube, YouTube sponsorships, conferences, that sort of stuff. And we tried a bunch of them and iterated through what might work and what didn't work and the pros and cons, the results. It takes time and effort to sit down just like it does with a product plan. And in our head, we sort of then mapped the unknown of marketing because none of us were, when we started the company, marketers, to product and engineering, which we all knew really really well

Pretty basic stuff, but it's helpful for us as product and engineering. I guess engineering on my behalf to have a mental mapping to to sort of like understand where you're moving in some sort of familiar world. We did that and then we realized that content marketing was pretty good for us early on. You need to write about you're doing in order to gain trust. For us in particular, we run your product.

Not not the code and the execution, but the orchestration of set thing, the state, the queuing, that sort of stuff. And you need to trust us to do that. Because it's not like a derivative of your application like Datadog is. It runs your application and so the barrier for entry is quite high. So we need to just talk about what we're doing, how it's different, why it's important and interesting anyway to sort of gain trust.

You need some sort of credibility. If you go to a website and they've got no technical articles, but they are a technical infrastructure tool, probably would ask questions. Yeah. So there's like some obvious stuff that you need to do. We did that. That was pretty good for us. And then we realized that there's a bunch of stuff that works. There's a bunch of stuff that drives traffic. We ended up partnering with a few YouTube folks. I think that's been pretty good.

You wanna give people examples of what you can build when you build developer tools. Because if you can give people examples of what you can build and show them how it's used, it's much more inspiring and interesting than talking about an API. I think so. I I've been

It it gives you like Also we were talking about the mental model from market for marketing coming from an engineering point of view. And you can like map the two week product sprints to marketing and understand sort of, as an analogy, when I do this in engineering, I should do this in marketing. And when you look at the code and an example of an API or a product, like when you look at ingest step functions and the examples of how it works to build a workflow, it's so much better than reading the documentation of like, oh, this is how step dot run works and it's a code level transaction because then you're like, cool.

It's been like slowly growing. I don't think anyone's really truly lived the problem themselves dealing with CRDTs and live syncs of local data versus their background data in Postgres. Like, you understand from a face level that, oh, this must be pretty difficult. But then the website that you go on and all these different products will show you concretely, here's demo, here's how it works, here's the problems that it solves. And then it gives you some appreciation for the tech that they've built in order to solve it, which is a Which is modifier or something?

Yeah. Yeah. That was the one. We're talking about the same thing.

That's how people learn these good examples, which gives you inspiration and understanding of the tools overall. There's a bunch more channels that we need to test, that we should test. And as the company grows and inertia carries you on, some of the traction stuff that you do early on doesn't necessarily carry through like what we're talking about. And your audience might change. You might realize that you don't wanna target solo founders and you wanna target series a b and c companies.

Or maybe you were targeting larger folks and you wanna move more mid market to get more awareness. The traction channels are massively different even if it's the same product, the same problem, the same communication. And so we're we're also walking that path of how do the traction channels change depending on the audience and depending on the target customer, the the the ICP, which is super interesting. Because like, again, given what given the area in which we work, orchestration, triple execution, step functions, workflows, Some people know that they need that right out of gate. And they know that building using ingest is going to save them months of work Mhmm.

And that they can build much faster. Some people learn that after a painful lesson of trying to work with Celery or RabbitMQ. And I damn, I should use this. And so a lot of people have lived the pain when they get to series a or series b or series c. And so we've got a bunch of companies that are growing from the ground up with us, like the data AI folks who come from HubSpot, manage massive Kafka instances and are like, nope, screw that.

We're not gonna deal with all of that. We're gonna build an ingest because it'll be faster. But it's actually really good to also speak to the the mid size and the larger companies, like AvalonBay, the real estate company that owns all the apartments, like a bunch of apartments in America Oh, really? Now using us to do a bunch of the leasing stuff because they also lift the pain of dealing with bare metal and Azure and AWS Yeah. And they wanna simplify everything Yeah.

The audience massively changes how you communicate in marketing and in sales. And we're still going through that now which is really interesting.

So a company like that that's public cares greatly about risk, which is something that we were talking about with trust before. They care greatly about risk. They care greatly about will this do the thing? Is it trusted? What's the security? What's the scalability? And so on. And then a company that's younger cares about risk but takes way more risks. Takes way more risks.

Yeah. I mean,

And you can talk to them more about developer speed, DX, ease of getting started, which larger companies still care about. Fundamentally, if you're talking to an engineer at a YC company or if you're talking to an engineer at a public company, they still care about their life, how good the tools are, the experience. Yeah. Like, I don't think any engineer joins JPMorgan and is like, know, I love the CICD process here. I love going through 10 hoops just to get something in production.

Yeah. And so the DX is still good. And it's actually, in our experience, easier to walk the path of talking to smaller companies up the scale than it is talking to larger companies and trying to then do POG afterwards.

Company positioning is such a big deal, such a big deal. You can have like five products all doing the same thing and the positioning will totally change how they, their trajectory, how they sell, yeah, it's crazy.

And you you got one service over here talking to another service over here via networking. It will never be a 100% perfect. When things fail, you have an educational piece of why did this fail? How did it work? Why did it work?

And I think it's pretty easy for you to sort of assume that you've done something wrong or assume that you've built the wrong product or assume that something might be innately wrong when all it takes is small UX tweaks to show users, oh, this this went wrong because you fucked up DNS yourself. You didn't add HTTP to HTTPS redirects for example Yeah. As a dumb example off the top of my head. And I think like that's super interesting. So who how are you positioning the target audience?

Is it relevant to to the problems that you're solving is a is a really, really, really big deal. Like, I know that you the late the latest episode you had with eleven Labs is super cool. He's a cool guy. Yeah. He's a cool guy. Yeah. That was that was great. I'd love to meet him. I felt like he was talking about something where he was talking about bedtime stories with the Stephen Hawking voice. Yeah.

And he was like like, that's cool. The positioning for that particular thing where you get like indie developers or indie users writing voicing over a blog post is super different to a healthcare company that's accepting phone calls and trying to figure out is this person like, does this person have valid insurance? Yeah. And the messaging is massively different despite the product being the same fundamentally. And I feel like, yeah, that that like yeah.

It's interesting. We've we sort of adjusted our messaging over time to sort of honestly be a bit more technical so that we could self select for the people that understood the problem despite it being a little bit more limited in audience. Like we're not Yeah.

Yeah. And it's like a nightmare to follow the thread about what's happening. Because I do when we moved over to ingest, you have one endpoint, you can split up over multiple. You have one endpoint that just does the thing. You write some code, you roll it out.

There's no infrastructure, there's no queues, there's no event streams, there's no new Kafka topics that you need to create. It just does the thing and you get like branch environments and whatnot out of the box. And he was like, our engineers are so much better. But I sort of feel like you're right. Like, you throw up a throw up a back end, you throw up an API endpoint, you add something to it and you're like, you know what?

I could probably just use this key. Smash out a key. Smash out a word. Yeah. It does the job. Yep. And then as time grows, you're like, I've created a

You do the thing and then you take a step back and you're like, oh, fuck. I did something I did something and I'm not proud of it.

And there are so many steps to a patient flow. There are also conditional. Like if a doctor submits a treatment form and something hasn't happened within three days, we must follow-up. And if a patient submits something to us and the doctor doesn't follow-up within like seven days, for example, we are liable for care and the company is at risk and we need to do something. And those processes are just code.

But it's code that's like, do this, have some sort of queue that sleeps for seven days that reads some database state that checks if this particular thing happened and then it will throw something else into a queue to do some other thing and like similar to the company I was talking to today, following the needle through that is horrible. Coding and building those flows, engineering that was monstrosity and it was super hard to debug. And if you had the APIs that we ended up building for ingest, everything that took weeks would have taken like an hour. You could have five coded it. Dude, I wish that were

And none of them are particularly important except for maybe one or two that I go through and I find. And I'm like Yeah. Like things slip through the cracks in human processes all the time. And yeah, finding out what went wrong is really, really tough. And that's also one of the reasons that we were like, events are the way forward Because when you use us, you're not really building a true fully event driven system like event sourced, which is just jumping off the deep end without a parachute, hoping that you're gonna land in snow.

But you are sending events over to Ingest and you do have all of those stored forever and they are a really good audit log of everything that happened. And so in our patient flows back in my previous healthcare company, you would say, hey, patient did this, doctor submitted this form, a doctor then submitted this prescription. This particular thing was produced and then sent to the customer, sent to the patient. And you could follow the needle of all the facts that happened within this particular flow. Obviously, trading helps a great deal, But having the events to understand exactly what happened with all the data at any particular point was was great.

And then in your workflows, can say, step up, run this particular thing. I want this workflow to wait for this other event, wait for this thing to happen in the real world with this matching expression. And as soon as this happens, continue on with the workflow. Or if this doesn't happen within seven days and it times out, check if the resulting event was undefined and then handle the fact that something didn't happen in the real world in code and the API is like two lines of code. But then the interesting part is from a from an architecture point of view, the your controllers, your API endpoints, they don't need to know about anything.

They're just like, ah, this fact happened. This doctor submitted this. Send the event over. Any workflow that's listening and paused will automatically resume and you've got like really good architecture bundled in. That I hoped for the debugging but like it was always a pain. I wish that I had the system that we ended up building to build that company Yeah. Like so badly. Yeah. Yeah.

And it's like it it will start, you know, like it's this is the paradigm of like how you develop stuff is just different because it's like you're kind of just giving it like things to do but you don't really know what it's gonna end up doing and like you're handing off a lot more control. Yeah. And so I feel like, you know, tools like Ingest I'm sure, like you've got lots of interesting stuff to say around like how that's changing and how programming is different when you're kinda handing the wheel over a little bit.

And then I'll talk about just like the overall process of using AI and tools in general and orchestrating that. Fundamentally, when you're using Jest, you get event streams, queues, workflow state, all backed by a simple API. You define a function, the event that should execute that function whenever it's received. And then you can do step dot run and so on. And that's basically it.

It's a few lines of code, completely abstracts the underlying infrastructure. And that's pretty cool because then if you're asking AI, hey, when a user signs up, I wanna do these three things. Yeah. It can be like, blah blah blah, ingest dot create function. User slash sign up.

And it could be like step dot run, step dot run, step dot run. And then you hit deploy to wherever your existing code goes. If you vibe code in probably one of the one of the hosts that's like not not AWS. Okay. Probably one of the other folks. And then you're sort of like, you're done. Basically, you don't need to learn the infrastructure. Yeah. You don't need to learn Gafka. You don't need to worry about queues.

You don't need to set anything up on on Railway. You don't need to set up a Redis server to to manage the queue, for example. Yeah. You just, like, vibe code away the workflow and you you call it a day. You move on with life and everyone's happy.

The world is a great place. Yeah. If you don't do that, you have to learn the infrastructure and then you have to ask AI to maybe sort out Terraform, sort out Redis, and then connect to Redis, then give me a queuing buy in and so on. And that that's like a little bit of a pain. So I think like the takeaway, the TLDR is that higher level abstractions over infrastructure will probably always win versus the lower level infrastructure now for moving products forward because people build products faster, higher requirements, higher barrier to entry, people are vibe coding.

There's no tomorrow. Yes. It's amazing. But in order to do that, you need like high level abstractions to make it work which is like, the React is sick and React is a really good abstraction over UI state HTML and so on. And we're the same but for the backing infrastructure.

And yeah. I feel like that's that's like one interesting part. The second is like, yeah, the the the whole the whole orchestration of AI agents in general and how to do that is craziness, man. This craziness is super fun. Yeah.

We can't vibe good our product because like we're knee deep in building queues. I wish we could. We'd be like, hey, give me this completely fair multisenant queue please and it would just whizz out some we can't do that but you could probably do it with some you could probably do it with some of the UI and whatnot and it's crazy what you can do now. Yeah. If I can absolutely bananas in a really really good way.

Yeah. I was chatting with one of our users on Friday. We were actually both at some MCP hackathon and I met him, chatted for an hour and a half, he'd already built his entire thing for the athon in the car on the way over using Claude code on his phone.

And the model cut off date is basically like one of the questions I had is like, does it just enshrine all of the infrastructure that's been created up until that point? And if you build something new now AI just doesn't know about it so it becomes harder. Like it's crazy. It's like

Yeah. And then when people ask, you know, true build execution platform or workflow platform or serverless queues, they're like, use us. Yeah. And that's super interesting and something that I I didn't think was gonna be like a GPT SEO game. Yeah. But it turns out there is. Yeah. Which is wild.

Right? So like if you're on if you're running your own data centers, you're gonna have like very cheap like you look at like Cloudflare. Right? Like they have been able they they wouldn't be able to do what they can do unless they were like controlling everything and so they can do things for like cheaper than everyone else and still make a lot of money.

Everyone needs it. Government mandated, have to do it. It's not too hard to sell. And I'm not trying to undervalue Cloudflare here but the wedge is good. Yeah.

And then they could build out this global networking capacity so that they could absorb DDoS attacks, which were relatively big deal back in the twenty tens. Yeah. And then they could use that entire thing to say, well, now we're gonna do workers and all this other stuff that they throw on. And I feel like every six months, there's a new set of products that get added to the cloud that just never ending the things, which is great. And the level of abstraction was cool because they realized that building at this level fundamentally on the infrastructure side lets them build other things on top, which then cumulatively add to the the power of the platform.

Mhmm. For us, it's interesting in that orchestration of your product. The workflows, the step functions, the queues, so on typically have been relatively static infrastructure like Kafka. That doesn't really know anything about what your product does. And that level of abstraction is maybe too low in that Kafka versus Redpanda versus WarpStream, they're really great people, now work for Confluent.

It's all fundamentally the same. Your basic your your basic arguments are how does it scale, what's the cost and so on. How do I manage this infrastructure? And just as slightly different in that it sits a level above, but I'm too far above. You send it events but those events are properly typed.

We understand the event names because they run functions. And we understand how your functions run because you write the functions as regular code, but you wrap them with step dot runs great code level, step level transactions. And because we're aware of a little bit more about what's going on in your application, it's pretty interesting in that the code runs with the state no matter what hosting provider you're in. You can have it running on Vercel and then switch to AWS. You can write it in TypeScript and then because of the way your SDK works with the IDs and steps, you can switch it to go deploy onto EKS and it'll pick up where it left off even if it's like running for a month.

Mhmm. So it kind of actually makes where you run the code fungible. Like, doesn't actually matter whether you run on VSSL or AWS because the code does the thing no matter where it is even if you change it. And then it also commoditizes a little bit of the event stream stuff and the queuing stuff that's existed for like twenty years and hasn't really changed. And because it actually runs the code, it's interesting in that the observability data and the event data that generates is not necessarily a derivative of the application, it's actually part of the orchestration and the workflows.

And so that lets us do a lot more with this particular data in the future and it lets you get a lot more out of the product. Like if you send events to us, why can't you just get like real time Meteo and forward them to Snowflake? Why can't you query the events in ingest overall? Because we already have that data and we could give you an audit trail or an API over that data in general. And so like I had this long term plan building the company of like, well, here's where we start, here's what it gives you, here's the level of abstraction, here's where we go in ten years time and so on.

And that yeah. I think like for us, the wedge as well, to comment on the wedge was like, oh, serverless orchestration, which is hard and it's just never really existed. But then walking the path of of the level of abstraction to see what you can do and stack on to make the platform in a way compound. I think like back in 2010, all the startup folks were talking about like network effects of social media. And it turns out that like in our view, there's network effects of like products and platforms.

And you build this one OG product that might unlock five other things that you can then sell or build into your platform, the symbiosis. Oh, man. What a word. Sorry about this. I'm just coming up with all of them.

Yeah. The the the way that they work together increases the sort of it makes all of the platform better. It makes it all more powerful. So for example, Cloudflare, you get DDoS protection but then you also get workers and you get the whole edge stuff. And you're like, well, if I'm doing all that stuff, why don't I just use r two instead of s three with egress?

And it makes the the the product a little bit better. Yeah. We sort of have the same thing beginning with orchestration to other stuff that we will end up doing. But firstly, we just wanna make orchestration really good and that takes a lot of time and effort and engineering. It's really hard product to build. So we got a little bit of work to do to make orchestration as good as we want it and it's really good but we could make it better and then we'll start doing other stuff.

What is the messaging? Because even if you build a really, really, really, really fantastic product, it doesn't actually matter. The way that you talk about it is equally or to a degree more important and each one of them impacts your growth rate. You could have fantastic customer segmentation and pricing segmentation and messaging, but maybe pretty poor targeting on the audience. Or maybe you have all of that done and you're talking to the right groups.

Maybe you've got the right YouTube partners and you're doing the right content engineering, but your homepage, the positioning, the way that you talk about your product, the story that you tell is just wrong. And that single thing might be the thing that's slowing you down. And so distribution overall encompasses so much and it's the annoying part is unlike engineering, it's so ambiguous and hard to ping down that it can be really, really, really tough to understand what the right call is to make. So thinking about that from like first principles is particularly important. And then another one that we just always talk about internally is like, well, yeah, first principles and also just friction.

Making something that solves users' problems is ultimately what we're really doing, you know? Like you can play around with tech for tech's sake and that's cool. And I think as engineers, we innately love doing that. And I think that's part of the allure to building DevTools like, damn, we get to build really good technology and that's gonna be really fun. But ultimately, it serves a purpose.

And everything that you do is to solve that problem. And sometimes as engineers, we can 100% get sidetracked by the fact that we are doing cool engineering things, that's a trap. Watch out for that trap. Build things that solve problems which is the same advice that you've heard for years. So I wish I could be more original but I can't.