次を作る：Resendの「退屈な」メールを300万ユーザーへ育てた舞台裏と、エージェント向け開発（Changelog Interviews #687）

What's up, friends? Welcome back. This is the change law. You know what? AI agents, they cannot drag a pricing slider. That's how Zeno Rocha found out that Claude and ChatGPT were both telling people Resend was the most expensive email service on the market, which is not true. And the fix was simple. It was a marked down version of the pricing page served through content negotiation. And this week I'm talking to Zeno, founder and CEO of Resend, about building for agents as seriously as for humans. We discuss why following the RFC for rate limit headers matters more than inventing your own, and why agents couldn't care less about his animated icons and keyboard shortcuts. We also get into publishing your open API spec as JSON in the .wellknown folder so tools can actually find it, why agents demand granular API permissions, and the closed-loop system he's building that turns downvotes on Resend's in-app agent into draft PRs.

It's a whole new world. And speaking of a whole new world, I'm going to be live on stage at Resend Forward on October 21st, this Wednesday, talking to Taylor Otwell live on stage in the Builder Room. Learn more at Resend.com forward. All right, let's do this. Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of WorkOS. Michael, offer agents. I feel like this is burgeoning. It's kind of happening all of a sudden. What's the state of the world for offer agents? Yeah, it feels like offer agents is one of those things that nobody knows what it means, but it's very provocative. Everybody wants to talk about it. Practically speaking, I think there's two things here. The first is when you say auth for agents, you're talking about how do I get the data into an agent that it needs to be able to do its job. And for that, we built something called Workless Pipes. It's actually more of an integrations product.

It helps you take your agent and connect it to your customers' Google Drive and connect it to Salesforce and HubSpot and connect to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed. That's one type of auth for agents, a data access auth. The other type is actually authorization. authorization. It's like permissions for what the agent is going to go do. Because you've connected all these systems, but then you say, what capabilities does it actually have? How can I restrict the agent behavior so it doesn't go off the rails and go do a bunch of crazy stuff? That's a lot of stuff we're building today. We don't have a product announced yet for that, but we've been working on it. The third, I would say, is probably the identity layer for agents. How do I identify an agent by its name? That's really coming from the enterprise identity systems that are out there. If you look at Microsoft's Intra agent ID, they're doing a lot of interesting work there. There's also expansions to OpenID Connect and SCIM for agents. We're building all of this into the WorkOS platform. So if you're looking for an identity stack that will support agents, again, feature-proofing. WorkOS is a great place to go, but it's changing really quickly.

None of us were talking about OpenClaw weeks or months ago. And that's a new paradigm I think we're going to see, not just within consumer software but in the enterprise too. So it's an area of very, very rapid development. Well, it makes me think about agents versus people, and not negatively, but this world where we'll have more agents than people. You know, today we have 7 or 8 billion people on the planet. In the future, we're going to have trillions of agents going off and doing things. And so the challenge around identity and authentication for agents is actually significantly bigger than just how people interact. In the same way, like, you know, GitHub isn't going to work super well for agentic coding because you'll have so much more code getting written. The same is true for identity and permission and logging systems when agents start doing stuff like that. So we're building for that future today. All right, friends, the next best step is to do what I've done, which is use AuthKit. Okay, that's how I authenticate my CLIs, my APIs, my applications, all that good stuff.

WorkOS.com is where you go. Try it out today. a million users with AuthKit for free. You can't beat that deal. It's literally free. Again, WorkOS.com. Try it out today. friends we're back with my longtime dear friend Zanarocha a man of many hats of course Your most recent and most successful hat, I would say, is probably being a dad and a husband. I want to discount that because I know you're a proud father and husband. But at the same time, a very successful founder and CEO of Resend. Everyone uses Resend.

That's the best, right? Yeah. We care about email more than others. That's how I would describe it. I mean, when I first, if I'm being a little honest, when I first heard you announce Resend, I was like, why? And a couple whys. Not like, why, oh my gosh, what are you doing? But more like, why email? Like, why is email? I mean, I know how important it is, but it's such a boring, protocol-driven, kind of hard, minutiae, slow to innovate, you know, like all these sort of like seemingly negatives, but yet you took it on and then succeeded, of course. But just even you, like you were not in the email space necessarily. why obviously has Ima become the I would say epicenter of identity and then the epicenter of

distribution and then the epicenter of you name it what do you what do you know yeah I feel like those like for the longest time I've been searching for the most innovative idea right Like you hear about the entrepreneurs of our age, like Steve Jobs and how innovative he was. So I was always like searching for that. And during my time at WorkOS, I saw how much like a boring business can actually be incredibly successful, right? Like WorkOS was selling single sign-on. and it was the kind of thing that once people integrated, they would never leave. So, and I would see just like how usage-based businesses also grow over time. And if you go after like a big audience, like how expansion revenue also helps the business. So just looking from those things from the inside

and I was a complete outsider to email. Like, man, I was, and I still am learning on the job, right? Like, there's so many layers to email that are incredibly wild. There's like an email conference that I went one time. Like, wow. Pretty crazy email conference. Like, only the people who are running the spam filters at Yahoo and Outlook. Like, it's just like a crazy world. But man, I believe those boring businesses, those ideas that seem extremely like, oh, why do we need another one of these things? We already have so many different email services, right? And I just saw there was an opportunity. I feel like every 10 years or so, there's a new wave of tools and developers are looking for what's new. So I saw that with SendGrid and Mailgun.

They all have been acquired by now. So there's just a bunch of factors that made me feel like, you know what, I might not know anything about email, but I do know one or two things about developers and how they think. I am a developer, and I feel like I can just put myself on their shoes. And, yeah, to me, that's the most important thing, like being able to just have a lot of empathy with users. I mean, you can tell that you're a developer, obviously, with I don't know how much you play the key role in your CLI and even the commands and the way it composes, but just resend emails, send, and the way that composes from the from, the to, and the subject, and the body, of course, just the way it composes. You've taken something that I suppose should be hard, but you've made it easy. It reminds me a lot of Stripe even. And you mentioned like SendGrid and others.

You know, Stripe came about after Brainstree and several others were like already key major players. And they dominated because they simplified to an API. and they simplified to really, I would probably describe it as like core developer substrate when it comes to how you take and deliver payments. And they took this thing that was kind of boring, still is kind of boring, except for exciting to make some money, right? But they took this already had been done thing and global player, you know, the place. When you think about sending money or accepting money or payments or anything like that, You think Stripe, right? Totally. And they were obviously a huge inspiration to us. I remember going to archive.org and looking at their old landing pages. One of the first landing pages from Stripe had this tagline, payment for developers.

And that's the tagline we use at recent, email for developers. It's as simple as that. We're just articulating in the easiest way possible what this thing does. and oh my gosh, right? Like Stripe is a business that is so loved. Like good luck trying to compete with Stripe, right? But think about all the different industries where you don't have a start. Well, Block Troste, right? Doesn't Block Troste, I mean. Square is like the best also ran, you know, in a good way. I mean, I love a lot of folks at Square. I've got some friends at Square, and obviously Jack Dorsey is a dear friend of mine. I'm just kidding. He's not a dear friend of mine, but I know him. Okay, I was like, okay. I'm just kidding like I wish I knew Jack I've interviewed him once but that was about it but you know they're an also random kind of a way but they've also just like dominated in good ways too but now they're being dominated at the hardware level like the Clover and I can think of like two or three others I can't think of this very moment but several other players have sort of stepped in their space when they weren't really driving

it and you know Stripe just sort of stuck in the we're going to provide the conduit the API layer and they really haven't ventured further than that. I'm not sure of any hardware on their front, but I'm sure they probably does some collaborations, but I'm not sure of anything in particular, like Square has Square Terminal, for example. I don't know, is there a Stripe Terminal? I mean, maybe a digital layer, maybe a software layer. I think the beauty of Stripe is they solve one problem and they get that one problem and they solve a different abstraction layers, right? So when I think about my own journey as a Stripe user with recent. We started, it was like January 2023 and YC batch was kicking off, right? So I was like stressed out. Oh my gosh, what am I going to do? And I have to sell this thing. I have like growth milestones that I need to hit every single week. So I don't have time to build the whole Stripe integration. I barely had a product

and now like integrating payments, It's like, no, no way. So I use their payment link, which is just something you generate on the dashboard, you send the link. And that's how I was selling recent back in the day. Like I would go on a call just like this. I would pitch the product. By the end of the call, I'll tell my friend or whoever introduced me to that person. It's like, okay, so what do you think? Do you want to try it out? And they're like, I don't know. It's like, no, you should go for it. And then I would just send them the payment link. and they would either pay at the call or like after I would like keep bothering them and say, hey, can you please sign up for my thing? And then people would eventually pay. So that was like, I could code, but I decided to go with a no code solution because I just simply didn't have time. And then the next iteration, a few months later, we're like, okay, now this is obviously not going to scale. We need something in the product. So then we embedded those widgets that they have. So that was great. And then once we get even more users, like, ah, this feels ugly.

It doesn't really match our brand. Let's just use the APIs and the SDKs directly, right? So they just articulated, like, okay, we have this problem. People might have different knowledges, or even if they have the same knowledge, but at different stages of their business, here's a way to solve it. So that's why I feel like they are brilliant in the way they execute it. Talk me through some of the architecture from primitive up to usable product by a customer, for example. Like, help me understand, when you deploy to production, what exactly is Resend? Is it multiple application applications? Is it, like, Resend D running on a server via System D? Are you in Google Cloud? Like, where exactly? walk me through some of that architecture and some of the primitives that make up the service. Yeah, like early on, we were very intentional about deciding where are we going to spend our innovation tokens, right?

Every company has a limited amount of innovation tokens. And we knew that, okay, where do we think is the best place to put them? And to me, that was on the DX layer. So we started with thinking about like, okay, how do people actually create the email template? So then we built React email and we made it easier for folks to send emails using Taylor Wind, TypeScript, and React. Great. So we built that layer. We made it open source. We knew that we would never make money with that, but that was a great way to get users at the door. then we're like okay how do we invest on a SDK first world not an API first world truly believe that so okay then we invested super heavily on the node SDK but also SDKs for .NET Rust you know languages that would be you know maybe not as used

because they were either too boring or too new So we built those, and then we had the actual service, right? Okay, we're going to run this thing, how we're going to do it. And during the early days, we chose the tech stack that made us move as fast as we could. So we chose, and maybe I shouldn't name names, but we chose like the hottest deployment platform. We chose the hottest database platform. and we weren't choosing the boring parts of tech, just the things that would allow us to ship very quickly. And some of those vendors, they actually stayed with us for the longest time. Others, we just outgrew them. And we had many cases of that, like the queuing system that we chose. It was great until a certain point, then we had to move to another.

so at the end of the day we do have most of our software running on AWS right now and there are parts of that that we are like looking into either like building more of that internally others not as much we did rely on SES which is Amazon's email service to get started and now we're like, you know, we're sending billions of emails by now. So how can we just own the metal? So we are investing heavily. This is one of the most exciting things for me this year. Like we're going to own that piece of infrastructure. So it's going to be pretty exciting. But yeah, that's life at a startup. Like you choose a stack. It serves you well at a certain point. Maybe then you've got to move. but there are other parts that you know we still use and love and so on Are you involved in

the architecture then like with Amazon Web Services are you involved in like how your application is shaped there can you just talk me through what is it like to deploy Resend like you mentioned deployment partners things like that like if you had to today like in this podcast a fire broke out, you had to step in and do something, you'd probably fire up Cloud, maybe it's Codex, whatever. Maybe you're hand coding still yet, I don't know. But if you had to step in really momentarily to look at something, check a log, confirm something, and do a new deployment because of something, what is that process like for you? Yeah, we use CDK a lot. So in the beginning, it was all click-offs at the AWS dashboard, and then we're like, okay, this obviously won't scale. We look at Terraform, but we had a team that was very heavily using TypeScript, so we felt like, okay, CDK is a great way for us to deploy this in a good way.

A lot of our system was not designed as a – Everything was synchronous and then everything we had to keep rethinking. So we started adding queues everywhere. So we used SQS for those queues. We used SNS a lot for all the email events that when you click on an email, when you open an email, we fire those events through SNS. We used Datadog so heavily. it's definitely like all the other startups out there it's probably one of the most expensive line items it's insane how much they charge but it's insanely useful so we have SLOs for every single part of our infrastructure but we do have like Vercel in other places too so our dashboard or marketing website runs on Vercel we try to use TypeScript everywhere and I was like holding that fort for the longest time.

Like, you know, we're a TypeScript company, but then it comes to a point where that language is not the right fit for what you're trying to solve. So we have one piece of the infrastructure, which is the actual pipe when we're sending the emails, and we rewrote that in Go recently, like three or four months ago. so those parts are way more scalable right now but it's all very modular now Can you share some details about that Go rewrite? Like what was involved like what does the pipe do why does Go why did Go make more sense was it probably the binary the ease of reasoning about a binary is pretty simple, how to deploy that is pretty simple you know, a lot of good things about that really Yeah, so there are two different ways of sending email at Resend. There's one where you call the API of sending one email, you just go, right?

So we queue those emails. So even if the database is down, we can retry them later, all that kind of stuff. But those ones are fairly straightforward, right? You can also schedule an email. So there's that aspect that we have a scheduler that we could run. But that's still fairly easy. When we send a broadcast, which is this thing where, okay, I'm sending 10,000 emails all at once. How do I do that? So we found that if you just send 10,000 emails all at once, Gmail will look at that and be like, huh, this is weird. Like why are you sending all that volume all at once, right? So what every single email platform out there in recent does that too, is that whenever you're sending a big batch of emails, you have to separate and break down those batches into mini batches. You have to space them out as well. And depending on the size of the audience, so if you have 300,000 listeners or you have like 3 million,

we need to space those out so that you're not going to be trottled by Gmail, which is what happened. Gmail looks at those emails that are coming in and they might say, you know what, this is way too much. Like I'm not going to place them on the inbox right away. Let me see the first ones. And depending on that, I might move them to the right place. So that part was really tricky because you have one customer sending 5 million emails, but then you have, I don't know, dozens or hundreds of customers sending 5 million, 300,000 like all at once and we were struggling with concurrency with Node for all those batches and so it was tricky to handle that and Go is much faster with concurrency in that sense Yeah, I'd imagine how does it work to batch those, is that something that you give the user the choice of or is that a smart layer of the

platform where that platform understands how to shape things to your SNS partners, et cetera. How do you think of, how do you, how do you solve that problem? It's a smart part of the platform. So this is something we do behind the scenes to protect you as a sender. Some people that are like, oh, it sucks that I have to wait four hours for all my emails to be sent. Three million emails. I wish they would all go at the same time. Of course, you do wish that to happen, but at the same time, if you do that, you might have all of your emails landing on spam. So it depends on the shape of how many emails you're sending in the past. That's also important. So there's a lot of little things that we might do to improve your deliverability. that if you were to just move them and send to those inbox providers, they would just either throttle your sending, which is what you know does very often,

or send straight to the spam folder. When you fit this Go application in, how did you have to – did you have to completely deprecate and remove something from the system? Did you have to just gracefully, you know, blue-green it? How did you approach the swap? And how have you swapped? Did you swap it over yet? Yeah, we did. We had multiple false starts. Like, we would try to go with that, and then, oh, my gosh, something broke down the line. The shape of the email body and all the headers, because we were building this new system, Maybe someone would send an email with some foreign characters that we didn't anticipate. Okay, now we have to go back, fix that issue. So it was a gradual rollout. It took multiple weeks before we could actually have every single user using it, but it was transparent. No one knew this was happening.

We haven't even talked about it publicly. This is the first time that I'm actually saying, oh, we used Go at recent. Nice. Nice. I'm a fan of Go. You know, whenever I think about my thought matrix when it comes to that language, the first thing I want to choose is TypeScript because it's so versatile. It's obviously the language of this modern era when it comes to anything agentic, which is pretty much anything these days. You sort of have to embrace TypeScript. And the agent, the model, doesn't really need the types, but what it does enjoy I suppose maybe it doesn't enjoy it is the intentional determinism when it comes to like Zod and schemas and types and things like that so like all that the TypeScript does the agent doesn't need to remember the types but it does need that system to remain sort of like guard railed so it doesn't have to do these wrong things or the right things and so I tried to choose TypeScript

first but I find that more often than not, the better shape for almost everything I want to use is a simple binary, is literally a binary, not a bunch of files that I have to then deploy and maybe compile if I'm using Bunt or something like that, or make it executable if it's, you know, Note or something like that. So, like, just different things like that. You know, I find that Go really is the better fit in almost every case. I really just wish that Go had a better web story. like once you get past the system the API you know all those things of long running services you kind of I mean there is web stuff there but nowhere near obviously the world of JavaScript which is kind of a bummer I almost wish that TypeScript and Go would just somehow merge but maybe not I know it's a beautiful world we're living now where we can choose more than one language and we don't have to be TypeScript for life as you may have been

in the past. Totally. And like, I wish there was a Next.js for Go, right? Like, or even like an Express for Go. You obviously have a big ecosystem there, but there's something lacking when it comes to the web, like you mentioned. But yeah, it's just beautiful. Like the idea of like, okay, you have a system, you have all the tests and that's what matters. And you can just swap languages based on those tests. Like how crazy is that, right? Like if we decide in a year from now that, you know what, let's move from Go to Rust. Obviously there's some work to be done, but there's so much you can do with that test suite. It's crazy. Can you share how difficult or some of the things you did to make Go fit into your TypeScript world? I imagine you're sharing like schemas via Zod or something like that. So they're able to use the same types, maybe even borrow the same types? Did you have to build anything, any middleware in between the languages

to make them play better together? It was definitely a struggle because we already had a monorepo, but there was still some repos that were, like, scattered around. And for this to work, we had to bring them over to the monorepo in a more intentional way and try to reuse the types as much as possible. but we didn't build like a layer in between them or something like that. But there was definitely like some work, even like when you're setting up CI, okay, now we have a different way of building this whole monorepo. How do you do that? We use Turbo Repo a lot, but okay, how do we fit that with Go? So, and the software development lifecycle, right? Like now you don't necessarily have preview URLs as you used to in certain parts. Thankfully for this part of the system, we didn't need that.

But you start getting to those things like, oh, people simply don't have Go install on their machines. So now, okay, let's teach them how to do that. So there's little things like that. And we use Docker. We use like the traditional stack that you would imagine. but the moment you go multi-language there are the linter you use now you have to worry about that oh it needs to support this other language as well so you start to look at things like oh how we can use a different linter or same linter like so it'll be tricky test suites another one too yeah well 3 million users is a big deal last month is a big announcement I think it was like six months before that you were at a million so obviously you're growing fast uh i think we're in a unique era for a lot of services i think you're in the perfect scenario where you could be at which is kind of where i started with the conversation around being like why resend not necessarily like questioning your your direction but like really email but yeah really email you know what a moment where now we can automate so much with it And so I thought it was kind of funny in a way that here in 2026 you would announce an official CLI as if that wouldn have been like step one

Honestly, I couldn't deliver, build, or operate a service unless it has CLI. So I'm sure you have like an ops CLI in some cases for your systems, but a user-facing CLI is finally announced. So 3 million users, this new agentic era, official CLI. What's the nugget in there we can talk about? Man, I'm sure you felt that way too, but after January, it feels like the whole world changed, right? We're coming off the holidays, Cloud Code is here, Opus is here. and we felt like how that changed the market. Like it just changed in a big way. It changed the way we use different SaaS tools. I found myself like building my own little apps. But more than that, like the entire infrastructure as a service category, I would say, benefited from what happened, right?

So recent is growing a ton, but we're not the only ones. Like the companies who are being suggested by Claude, suggested by OpenAI, they are riding that wave the same way as we are. And it turns out, like, once you have those integration points, like the CLI, things that you would imagine, oh, they're so silly, right? Man, the things you can do once you have a CLI, like, that was, like, impossible if you didn't. or now with MCP, like, it's just insane. Like, I see people and I see myself using Cloud Code work as my operation system. And I do work from that. And having those integrations in place is super important. And then the tools that don't give me that, I'm like, I just can't use them. I'm like, I need an MCP server. I need a CLI. like there's no negotiation.

Like I would just move to something else. Yeah. Yeah, I feel like, which is kind of the comical thing here is here we're in 2026, officially having a recent CLI. What took you so long? Yeah. Were you just too busy? I know in three years' time you've got so much to do, but like seriously, Why did it take you until this year when the boom happens to make an official CLI? Yeah, that's a great point. That's a great point. We built CLIs over time internally, like during hackathons and stuff like that. But I've always felt like, man, who's going to want to send an email from the terminal? like we are trying to help businesses to send, you know, transactional emails, reset password, welcome emails, like whatever you need to send, right? Usage emails. But would someone go and like spin up their terminal and try to send an email from there?

My feeling was like, oh, maybe not. But it turns out you need all these other tools around it, right? like you are configuring a domain, you are looking at your logs. Those things are extremely valuable to have on your terminal. And then when this whole craziness happened, we just had to build one. Like for myself, I was spinning up all these OpenClaw instances internally for the team and for my own use. And there was no way I would have to give my OpenAPI spec. it will generate a super poorly written CLI based on that. And I just hated that. So we're like, no, let's actually build one. We chose TypeScript for that one because we wanted to make it open source. We debated using Go, but we just said, you know what, let's just go with what's better for open source contribution rather than just deployment or build

or performance necessarily. And, yeah, it took us a long time. And it took us a long time to ship the MCP, too. With MCP, what was hard was we built the MCP server, we made it out there, and then all the MCP clients now require like an OAuth authentication method by default. So we had to go back and say, okay, now let's revisit our whole authentication layer and how we save every single request, how we do everything to support not just a single way of authenticating requests for an API key, which is what we had. Put your bearer token on your headers, you're good to go. So we had to rethink the whole thing, deploy the whole thing, think about like auto trailing and observability for MCP service, which is a new thing that's emerging too. And then now finally we push up like a hosted remote server.

So, yeah, it's crazy how those things take longer than you want, those interfaces. So I see that as an interface layer. And at the same time, you have users asking for the product layer. They want features. Of course, they need different interfaces, but they actually want different ways to interact with email. So for us, we started with marketing. Then we started with transactional. Then we added marketing. and people ask for a way to receive emails, so we added that. And then they ask for automation, so we added that. So we have all these different things you'll have to build to actually solve user issues as well as improve your interfaces. It's crazy. It's just so much to build. What does it take for you all to receive an email? Of this list, the things that really stand out to me is receiving an email, broadcasts and automations, but that's just my take. Yeah, receiving is tricky because first, just the setup can be tricky. You add an MX record,

but then if folks use Google Workspace, now there's like a competition between the priority of the MX record. So you got to deal with that. You got to teach users how to deal with that once there's a conflict. So that was one challenge. And we think a lot about friction, and that can be an action that if someone is just distracted and they try to set up in a way, they might break their whole organization, and they don't even know, oh, my emails are not, you know, I'm not getting any. There's no observability for you to, you know, for like, oh, I broke my MX record ordering, and now things don't work anymore, and I can't even tell you it doesn't work because I can't receive or send email. Oh my goodness, man, it's insane. It's crazy. And then with receiving, you don't really have control over what you receive, right? You do have control over what you send. But what you receive, it's a wild world out there. And people are sending spam to these wild card usernames, like support at whatever, security at whatever, sales at whatever.

So you got to do with that too. And you're just like, you're walking around out there in the marketplace, Zeno, with a target on your back, basically. You know, like, just take us down. We're dealing with the hardest problem here, especially the inbound. How did you approach, how do you approach that specific problem set? Do you, like, how old is that product? And when you thought about it, did you sit in a room for a week and just dream about where it can go? and what that first, like, even for the first thing the user needs, like, what do they need? Do they set up an email inbox? Do you automate it for them? You just tell them records, and they're going into Cloudflare dashboard or wherever, you know, they're doing their DNS, DNS simple, or, you know, wherever they're doing it. Like, how do you even approach that kind of problem? Yeah, it was a wild journey because the first thing is, like, man, I got to feel the pain myself. If I don't feel the pain myself, then there's no way I'll be able to build a great product.

So we were like, okay, looking for use cases internally that we will be able to receive emails, triage them, automate, like, okay, based on a support message. Let's not necessarily reply, but draft a reply for a support team, whatever it might be, the use case, right? So it was a journey to get to that. and then there was a journey to, like, first of all, users were crazy about this. This was our number one most requested feature for over a year. And we were looking at that. It was always at the top. Like every support ticket we have, we use Plain for support. There's a way to link to a linear ticket. So we link every single feature request and this one, the frequency was just so freaking high. So we're like, okay, it's an obvious problem. People want us to solve that problem. Let's go try to solve that problem, right? Similar to SMS, what's happening to SMS right now with us,

but the problem is I don't feel like I'm feeling the pain as a user. So that's why I've been a little bit hesitant to dive into SMS because I haven't felt the pain. But with Inbound, we started feeling the pain. We started to learn about the user's pain. and then you're talking to your friends. I'm like, okay, dude, what are you using? What are you using? What's the biggest problem? And you're uncovering those things. And although we are a remote company, I love picking three or four engineers and just locking ourselves in a room for a week. So then I remember I traveled to Sao Paulo where we had a few engineers that were joining the team and then a few that were there already. So I think we're in five or something. And then we just kept like building that V0 of inbound. And the reason why I love doing that is because you have to make so many tradeoffs as you're getting started. And you're in the room. So the team is like, oh, I have this blocker.

Great. Let's just do this. Let's just do that. And you're feeling the DX as you're building as well. And then you uncover all the – now you have known unknowns. Great. Now we can go back home and actually build the thing and actually make the thing work. But I love going – I got to feel the pain. If I don't feel the pain, it's just – I know that the end product won't be as good. And not because I'm special. It's just because I won't have the empathy. I need to feel like, oh, this sucks. This looks so bad. and I go through like Dracula and that's why I'm like no I go to my Dracula domain which I do use the Google Workspace and I'm like now I have to configure the DNS settings okay but oh the conflicts oh what do I do now like I'm lost like how do I overcome this so that's why I love

having side projects until now because I can always use them to feel that empathy Is this mainly giving, I don't want to just say like an agent. We've said an application in the past, but I feel like now our application layer kind of has an agent to some degree available or nearby. Is inbound about handing an email address specifically to an agent or an application layer? Like how is an inbound user? What was that pain you mentioned? Yeah, there are many use cases with inbound. So there's one company that we help them. They do trip management. It's called TripSee. Amazing app, by the way. You should definitely check it out. It's beautiful. One of the most beautiful iOS apps I've used. And what happens with them is like, oh, I just booked a flight or just booked a hotel.

I need to forward that email as a user to this special address, and then that address will then receive that email, and then will parse the whole email. It will use whatever it wants to use, either deterministic or it will use AI to extract the information, then save the information, right? This is one use case, and it's a use case that I like a lot. You're forwarding a PDF. You're forwarding whatever you want. or a CRM where you are adding a BCC and that gets the content of the email and saves that email. And the reason why I like that use case is because it's more B2B. But then you have the B2C type of use case where I'm setting up my open claw, I need it to have an inbox. And I need my agent to have an inbox. That's it. So then, okay, now I need to set up an inbox. I like that use case. We're building around that too, but it's a less frequent use case.

It's something that the volume is not as much, but still a pain. So it's hard because we're trying to solve the problem for both. There's the wild card solution, which is what recent is right now. You set up inbound. Every single domain, doesn't matter the address, it goes there. Now what we're actually building, and it's looking really, really cool. We haven't shipped that yet, but it's a full-in-box UI for you to interact. And obviously, this UI will come with its own CLI and MCP server. Well, friends, I'm here with the CTO of BuildKite. And one of the most challenging problems of modern era software development is continuous integration and continuous delivery. And so Lachlan Donald, Bill Kite, CTO, what are you thinking about today's teams, the challenges they face, the speeds at which they're developing new features, new code?

It is just overwhelming. How do you all think about that? Such a good question. It's the question everyone's asking right now. All of our big customers are asking us at the minute, like, you know, if we 5 or 10x our throughput this year or 1,000x it, what breaks and when? And, you know, my answer is kind of same as it's been for the past 20 years, which is that the bottleneck is still trying to integrate those code changes in and then deploy them and check they work and then keep them working as you keep throwing more and more code at it. I think a lot of the fundamentals are the same, but we're just a thousand X-ing the speed of it. And, you know, that changes nearly every variable. Yeah, for sure. OK, so where does BuildKite thrive? What particular type of team or enterprise do you thrive in? The area that Billkite has always thrived in is like this like fastest moving tech companies of the world. Like we've been disproportionately successful in that small niche. The kind of Shopify class, Uber class, you know, open AI class of folks that have this key problem around iterating really, really fast.

And, you know, the thing about all those folks is they all have subtly different needs, subtly different problems. And so we've tended historically towards building like really well engineered Lego blocks that scale like orders of magnitude more than what our nearest competitor does. So, you know, I think that that puts our system in this tension where, you know, you've got to spend some time assembling those building blocks, those Lego blocks to get the thing that you want. But the end result is far and away more performant and scalable and the experience is better than what you get from something that's off the shelf. So I think we've started from a position of really well engineered logo blocks and then are kind of working backwards towards kind of creating the thing that scales down to a startup that starts with one person and 10 agents next week. Well, friends, go to buildkite.com. That's buildkite, K-I-T-E dot com. You deserve better CI. Engineer for the frontier we are all facing, trusted by the teams setting the pace.

Again, buildkite.com. Once again, buildkite.com. When you were designing for an agent like Open Claw, for example, how close did you come to identity? Did you teeter at all around anything where now because – because I was actually thinking about this recently. Like here in the United States, one of the ways you define your societal identity, like if the police for some reason came to your house, nothing bad, But they just came and they said, I need to see your identification. We're just doing, you know, for all the reasons why it's fine. It's fine. They ask you this. What do you hand them? You don't hand them. Maybe you hand them your hand if they're going to take a fingerprint. That's weird. So you can identify that way. But the most common way we do it today in society is with a driver's license identification. That's an API key, right? It's got a driver's license number on there.

You hand them a physical card, but you basically gave them your API key. Like the API to you, the key for Zeno, the key for Adam is my driver's license. And so I'm curious how close you came to thinking about identity when it came to giving an agent inbox. Yeah, man, I actually thought a lot about that. And we obviously had the news this morning about BetOff being acquired by Grissel. that Twilio also acquired an identity company. So for a moment, I thought about that idea because I take a lot of inspiration in terms of what the connections that other products were able to do, right? So to me, PostHog is brilliant because they saw something that no one saw. Like I was using Mixed Panel and those tools forever, right? like Amplitude for product analytics,

never I thought about putting feature flags and product analytics in the same product. But they are adjacent, right? Once you have those events, now you've got to figure out what to do with them. So that connection of what happens before you use someone's product, what happens after someone uses someone's product, that to me is really, really interesting. I ask that a lot to our users to understand, like, okay, before I use recent, okay, maybe I'm doing this, and then I do that. Great. So identity is one of those things. Reset passwords, magic links, you know, there's a lot there. And I haven't cracked the code for recent yet. I haven't made that brilliant connection that, oh, my gosh, now it makes so much sense. It could be background jobs because no one sends email or most people don't send email right away. They put those emails in a queue or in a background job and then the outside of the critical path, right?

So there are adjacent things that we could get into, but so far it's been, man, we just got to focus. Like there's just so much to do. Those 3 million users are asking for so many things here. Let's just stay in our lane, at least for now. Now, we are obviously expanding the footprint of the product, but we haven't taken that extra step to go into a completely different vertical. So those 3 million users are probably pretty, to some degree, vocal. I'm sure there's at least one-third, maybe one-fourth that are more vocal than the other 75%. Maybe not. I don't know. What are some of the things that they're telling you that makes you know, like give you assurance or some version of assurance that we're going the right direction? Because when you have a swath of a large swath of users telling you which direction to go, you kind of you kind of should listen. Right. And so are they saying I want identity with my email?

Like what are some of the things that are really pushing you towards when it comes to product? I hear a lot like phrases like, oh, I want a reason for a WhatsApp, a reason for SMS. Twilio sucks. Can you please make my life a little bit better? You know, and, you know, SendGrid is now completely folded into Twilio. They're rebranding as Twilio email and it's inside their dashboard. They're taking off the domain and everything. So Twilio is our biggest competitor, and it's hard not to look at them and be like, you know what? They're just adding more friction, and we're all about making things easier. Their SDK is not as great as it used to be. So there's a lot of things we can make it easier there. So there's a lot of push towards that direction of like, okay, recent is great for email. how can it be great for my entire communication portfolio, right?

If I have to send messages, it doesn't really matter which channel. Email could be one channel, but I'm just trying to get to users. It's a comms channel, really, right? It's a comms gateway. They want one place to go, one API to call, one dashboard to look up, one log to reason, et cetera. Exactly. And I feel like that's the future for a reason. I think at some point we'll get there. But time and time again, every time we went to this road and we could turn left and go deeper into the email space or turn right and open a new channel, we always turned left. It's crazy how deep email goes. It's insane. I'm always amazed at how much there is to build still. So, like, I'm sure, like, we have roadmap for the next 10 years easily. Like, even if we just stop paying attention to everything, there's just so much to build.

Wow. I'd imagine in this era, too, you have a lot of pressure to deliver something very, very soon. What are some of those things that you have to deliver very, very soon? Like, what kind of customer types are they? They tend to be humans, community agents. So, technically, it's an agent. You know, what are some of the shapes of what you're being asked to deliver so quickly? You know, we spend a lot of time on the website to make it look good. You know, you go, you see that crazy Rubik's Cube and you just... I love that. Or you go to the dashboard. We also try to make it as fast as possible, all that kind of stuff. The SDKs, the CLI, the MCP. but at the end of the day, if the email doesn't land on the primary inbox, you know, it's all for nothing. We could have the most amazing open handbook about how we operate,

but if the emails are not landing, if the servers are down. So that's where we try to spend a lot of our energy, like let's make sure we have a solid foundation. We started the company thinking we were building a dev tools company, and I quickly realized that no, no, no, no, no, you're building an infra company. Like the moment we had our first downtime, I knew very quickly like, okay, this is a different type of business. Yeah, now you're utility now. Yeah. People call you, they expect you to answer quickly. Every time. Every time. Yeah, like go there and flip the light switch on. If it doesn't flip on, you're like, who didn't pay the light bill? What's going on? Like you expect it to be there. Where is my resend? Totally. And for some apps, it's like, oh, it's okay. I'm just sending a marketing email. It's fine. For others, like, no, my users are not able to log in. Like, you guys are, like, letting me down.

Like, there's no way. So then we have to jump super quickly. And we have a big success team. My big, I'm talking five people. But we are trying to be spread In as many continents as possible We now have people in APAC Like New Zealand, we have people in South Africa So we need that kind of distribution We cannot just be isolated in a single region Even as a team We're a team of 45 now It's a pretty small team still Yeah I don't want to ask you this question with a negative, but I'm going to do it just to get a reaction and just to dive in a little further. But like, is 3 million users a lot? Is that a lot? I know it's a lot when you go from zero, when you have zero strangers using your software, you know, I get that that's a lot of users, but like, is that really a lot in the grand scheme of the space you

fit in, given even the change, you know, with SendGrid and others, like just changing around the scenes, like you seem to be the most, you know, Stripe API, amazing DX, I would say maybe even now borderlining amazing AX, Asian experience. Is 3Main a lot? Is that a lot? Yeah, that's a good provocation. I saw recently that Superbase had crossed like 10 million users. That got me thinking, like, oh, is this the TAM for developers? Is that how big it can be? I forgot now, but on the Twilio website, it was also around that. So I'm like, okay, how far can we even go? To me, what's interesting is like the definition of a developer is completely different, right? so if we're building for developers what really is a developer

these days crazy story man I was at Vercel Ship last week in New York City and you know I was at the booth talking to people and it was great because Vercel Ship is different from Next.js Conf you can tell the vibes in the audience there's a lot of VPs and CTOs and CMOs all that kind of stuff and during the afternoon I had just finished lunch and a guy that was working at the catering company he was like with some dishes he was walking around he stops me and he's like oh are you from Resend oh I use Resend I was like no way tell me more I even took a photo with him he's like oh yeah like I'm trying to learn how to program on the side and I use Lovable and I use recent. I don't use Rysel yet. It's too complicated, but I use these tools and it's great. I was like, man, that was so special to hear. And I'm just reminded, this was like, I don't know,

six days ago. I'm reminded about, you know, the people who are serving. We do have email for developers as the tagline. We have so many designers, so many, I don't know, product managers, marketers using Resend, and builders. I feel that that's what ultimately these people are, right? So how many builders are out there? It's way more than 3 million, you know? And that's why I'm excited. It's like, how do you build something for that audience? They are completely different. They don't know how to troubleshoot. Once they have a bug, they are just stuck. It's crazy. I've observed that already by answering the tickets. They just say, my email is not working. My email is not sending. Like, okay, help me. Give me something. I want to help you. Just give me more data. What is the error code? What is the error message? I want to help you, but just give me more. They don't have tolerance for those problems.

If it's just too complicated to set up. If the time to aha moment is too high, they are not going to adopt it. But man, if you can get there easily, you can make their lives easy and they can just get started quickly, they reward you. So yeah, I don't think Trimillion is a lot. I feel like there's way more to go. Way more to go. You know, you mentioned that user. I got a friend of mine. I'm going to mention his website. I was, that's why I was looking at my phone right now. If you saw me looking away for a moment I was trying to think because a good friend of mine Hamilton Heald he and his wife started this beef tallow chapstick brand called Meadow and Hyde And it's meadowandhyde.co for example. And when he told me he built his website with Bolt, I think it's bolt.new,

and he said that he sends his emails with Resend. I was like, what? Same thing. in LA with you after lunch and this fella. It's not that they shouldn't. It's peculiar now. It's the new new, right? And my buddy Hamilton is a smart fella, but he's not a software guy. He's not a technologist necessarily. He's inclined. He's not foolish, but he's not really a developer like you would consider a developer in the past. Meanwhile, he's built, if you go to meadowandhide.co for example, You will see a really beautiful website. Well done marketing message. Very clean and clear using recent, of course, as you know. And I just think it's so wild. You've got these folks now that are using services. The way I tell people like this is like with an API key even. To use recent, you have to use your RE underscore API key.

You're going to get this API key. And it's like your driver's license in a way. In this case, maybe it's your ability to access something. I don't know. It's a key. It's so interesting in this world, like, to explain what an API key is to people, like, I don't know what you're talking about. What does that mean? It's just a key. Like, you take your keys out and you say, this is a key. This is a digital version of that same concept, and it's got the certain grooves and, you know, cryptography. That's basically physical cryptography, If you went to like the shape of a key, for example. And now we have people who would not normally be using API keys, requesting API keys, needing to have even a particular account type. So you might be using a service that in the past has been pretty foreign for the user to ever ask you for your API credentials or to create an OAuth2 application inside the dashboard. Now this question is becoming more and more the case where people need to do that and even having to have a particular account type to get access to that.

In the case of where you charge per user, for example, you want to have someone on your team and maybe this person's newer that they are your tech seat person. And in that tech seat, they're procuring your API keys. Maybe they're even weaving together services, and they're not in the command line. They're inside of Lovable. They're inside of Bolt, and they're inside of Cursor, for example, and they're weaving together these keys and stuff like that in these services in this whole new world, and it's kind of wild and exciting at the same time because my buddy building a service and his website, I was like, what? And he showed up to me. I was like, dude, this is good. Like, this is good stuff, man. It's not vibed at all, but it was vibed. It was a version of vibe. But here he is shipping products to people physically and using Resend to send the emails. That's wild. So he's one of $3 million for you.

Yeah, it's insane because you see how much empowering technology can be on the grand scheme of things. The things you can build, the fact that with plain language you can get stuff done, it's also so beautiful. And it's also super challenging, too, because if you're one API key away from doing whatever you want to do, you can do a lot of bad things, too, if you don't have the right intentions, right? True. So we have a big challenge in, okay, we want to make it as easy as possible. Great. How do we deal with those bad actors? Because there are weird people out there trying to send some weird emails. And we block a lot of them and they keep coming back. Now it's a different version of that too. Maybe last time, if we even talked about that subject.

Maybe a couple people coming in, recurring. Now we're talking full gangs. They are spam gangs. They have thousands of domains. I'm not talking 10, 20, 100 domains. Thousands of domains with different registrars, different DNS services. and they all try to take advantage. And if you have a free tier, good luck. You know, that's an added problem to this thing. Yeah. You want to make it easy. Yeah, but it's so tricky. Like, for example, account provisioning. Let's say you just want to do that programmatically. You want to hit an API to even create an account to be able to create an API key. Those are the things I started to see when I was spinning up my own agent. I'm like, go to recent, try to create an account. And I had a bot detection at first on the signup page. I'm like, no, I'm removing this thing.

This is not going to be here anymore. So I just rip it off. I rip it off. This was like a Saturday afternoon. I rip it off and I'm like, no, we're going to have bot detection in the login, but not on the signup. And then you try to make things easier. But, yeah, it's hard. But then you'll hear those stories and, oh, my gosh, it's just beautiful, the power of these models these days. And people with great ideas can just make them happen. You bring up a good subject, which is the free tier. And I know that you have a free tier. So you got a zero per month, 3,000 emails per month. You got 10,000 automation runs. So you're giving quite a bit there, and this is all in the name of attracting customers, right? They call these trials, like your trials convert. How difficult is it in today's world, given the upswell of interest in Resend, is it to honor that gift of free tier?

Yeah, it's hard. I think we just invest so heavily in that anti-abuse program internally. We have so many systems that we're building. You actually need a lot of staff to cover for this too because abusers don't stop. So it's hard. And we were doing like an exercise in like, okay, think of like crazy ideas, go insane, moonshots, how we can make this one part of the company easier. And for trust and safety, like one of the moonshots was like, oh, let's kill the free tier. You know, in one second, we're going to like remove all those problems away. You obviously create many other problems and it just doesn't really speak to what I'm trying to do. You know, starting as a software engineer in Brazil, I didn't have any money for the services that I was using.

And thankfully, GitHub had a free account. So I was able to get started with that. And then, you know, as I was building, there were other like the free tier is something that enables, you know, a new generation of people to get into tech in the first place. So to me, like there's no way we're going to get rid of the free tier. and of course you're not doing that too just because you are like the most generous person in the world those people actually convert uh in fact just today uh this morning we crossed 100,000 paying customers so three million users total 100,000 paying customers and it's just like if you have the right incentives the right levers at the right places uh we had to add those to make sure people like so it's 3,000 emails every single month for free but you do have a daily cap and those things help us move users from one tier to the other but they're still generous enough right

like it's 100 emails per day if you're sending over 100 emails per day okay maybe you have something going on um so then okay now you can pay 20 bucks it's not the the craziest thing but still is for many people then I have to you know shut down that service or not I think for me, it's a dual thing. It's both like a do-good type of thing, and we even articulated that. If you go to our philosophy page on the recent website, that's the first thing that it will talk about, like make it for everyone. So we talk about how there are developers not just in New York or San Francisco or London, like, no, they live everywhere. They have different access to the internet and the latest technology. So we're trying to make something that can actually help and be used by a lot of people, even the users at the margins. But there's just a fact, I believe, if you have a go-to-market motion where you're trying to win the masses,

the moment you gain that mindshare, it might be easier for you to gain enterprise mindshare later because now you have established name. Now the models are recommending you. So it was interesting to see that dynamic too. Last year, January 2025, Lovable, Bolt, V0, man, those guys, they were driving so many signups recent. But our revenue was just like growing the same way. January 2026, completely different. Because Cloud OpenAI, they are recommending Resend, but those are actually paying customers that had the problem and we happen to be at the right place at the right time, right? So it's a different type of user, but you shouldn't neglect them. Yeah. Even if they're not paying you right now. that's a good point i mean really it is i mean you can scrutinize it's almost like

long-term thinking versus short-term thinking right your short-term thinking is like all free tier is bad long-term thinking is like no actually free tier is really good you just gotta get past the pain of it you gotta like look at it as a non-burden and look at it as a praise and a a boon potential if done right but that means that you've spent the right kind of time designing your pricing tiers? How much time do you personally, as CEO, think about free pro-scale enterprise? Is it on the daily? Is it once per week? How do you think about your tiers? Oh, man, I think about them all the time. Not daily, for sure, but I see people like, so, for example, because we have those levers to help people transition from one plan to the other, people are always complaining about those levers. So in the free plan, it's like one domain. And people are like, oh, I can't use recent because it's only one domain. And then they try to create multiple free accounts to bypass that. So there are things that you do to try to accommodate for one thing and then you lose the other part.

So I think about pricing a lot and positioning too, right? So we could have like a cheaper first plan. That's like people ask that all the time. Oh, I wish, like $20 is too much for me. I'm in Africa and it's a lot of money, right? Okay, so let's make it $15, let's make it $10, let's make $5. But then how is your product perceived the moment you change that to, right? So we're trying to position recent as this premium product, a product that you go and you feel the love, you feel the care. so okay pricing is a part of that too we messed up pricing so much I think we got it right with transactional emails with marketing we charge for contact and in this age where you launch an app and now you have a million users out of nowhere pricing for contact doesn't make sense

so we are revisiting that too so some decisions we made because we're like oh let's just follow the market It's just easier. Like, we're not going to innovate in pricing. Let's just mirror what our competitors do. I feel like that's a great idea at first. But now you realize, like, oh, no, what a dumb decision, right? Like, pricing is part of the product. You cannot get away. Look at any, ask any SaaS owner what's their most access page after the landing page, and they will tell. It's slash pricing. Like, that's the page. So it's part of the product and you cannot ignore that. Well, on the copy front of your pricing page, it's stellar. This is probably the most clear page I've ever seen in my whole life. There's no fluff. It is exactly what you want on a pricing page.

I'm not sure what role you personally played in this, but the slider of helping you choose which tier, like people want to know not just what do you offer and how can I pay you to get what you offer, which is a pricing page. But how much does it cost? At what point do I graduate to a new cost? How does that scale with my developer base or my user base or my send base? So, you know, pick whatever metric you're comparing against. then obviously you're going to always have that enterprise tier on the far right hand side. I feel so bad for those enterprise folks. It's always in the far right. But then you've got this slider that really shows you like, oh, once you get past a certain number here, clearly you're in the scale custom enterprise realm. And so you almost sell them with facts. You're not selling them with like probables. If this could probably happen or these, you know, this is exactly what you're going to do. like if you're going to stand in the 500,000 range,

you're probably going to be in the scale territory. And to me, that's really cool, like how you designed this page. But how do you see this page changing? I know that I can't recall what it was. I think I saw you do this where you just added a .md to the end of things. I think, did you start this movement? I said, no, I think this is you, right? So how much traffic is this page getting that is non-human now, that's still influential? and how do you influence the non-humans? How are you influencing these agents? Yeah, that was funny because as you were saying good things about that page, I'm like, yeah, that page is good, but it's good for humans. It's terrible for agents. Yeah, well, I mean, maybe operably. Do you give them some version of maybe this is an API, it's interactive, and, you know, I don't know, like pricing is an API page versus that. And you're like, how do you get your pricing?

Well, tell me what your payload might be like. How many emails do you want? How many will you send? Is it transactional only? How many per day? You know, and all that is maybe an API call and the response is JSON. It's like, here you go. Or maybe it's market. Maybe it's actually markdown. I don't know. But anyways. No, totally. And the way I found out about that was, again, a Saturday afternoon, I'm just tinkering with stuff. And then I asked, like, oh, I was creating maybe a competitor analysis on Cloud and OpenAI. I wanted to see what they would recommend. And then they told me, like, oh, Recent is the most expensive service. And I was like, no, I know for a fact that this is not true. Yeah. And I was, like, so surprised. And both of them got it wrong. And then I was like, okay, let me uncover this. So it turns out that agents don't really like JavaScript-enabled sliders. They cannot slide.

That's not something they're able to do. And I'm like, okay, we need a markdown version. So I made the markdown. I changed the alternate header. So if you were to request that with a different header, then it returns that. and then I just started to like seeing for real life and then I just made the requests and then started to get the math right. Like all, so what I did was, okay, I'm sending 3 or 2.3 million emails a month. How much would I pay with recent? And then it would get the number wrong. And then I was like pushing changes. I was like, oh, let me update the copy. Let me update this. And then when I added the Markdown version with an alternate header for content negotiation, then it finally worked. So I was like, oh, okay, nice. In the end, if you're not playing with your own products or if you're not putting yourself in the shoes of the users

as they're considering your product, then it would be impossible to uncover those things. No one came to me and said, like, oh, your pricing is wrong, or my agent is telling me that the pricing is wrong. I haven't heard anyone tell me that. What is that cadence for you? How frequently do you sit down in the place of the user? Is this something you have blocked in your calendar? How do you approach this, you know, must feel the pain, act as user advocate that you are? I'm always looking for excuses. so I operate on that. So I'm like, oh, okay. We have an all-hands meeting, for example, every Monday, right? So we used to use a Notion doc where everything goes in, they write their updates, and then we go through that doc together, and that's it. So, oh, okay, this is cool, but what if we just use our own product for that? So you have to create a broadcast.

Then we all went to the editor together, and man, it was such a mess because guess what? We didn't have multiplayer so it was a terrible experience editing together that email. So then we built real-time multiplayer with live blogs and then, okay, now we have something that works. So we do that every Monday. It's a ritual now. We go, we write the update together. By the end of the call, I send the email and then it goes to all the employees of the company. I obviously send every month like an investor update to all my investors. I do this religiously. I never miss one. It's always on the first day of the month. And I try to make it like very, very early in the day. And I do include all the lovers and all the haters of recent. So if you're a lover or if you're a hater and you tweet about it, I will see it and I will include on the investor update. and I just keep inventing those excuses

like right after this call I do need to send an email for Dracula where they have the draft done and I'll just go ahead and send it so I'm always like coming up with whatever reason I can to yeah, to use the product That's cool man I feel like that's definitely the way you uncover the real potential too, right? Not only uncovering all of your blemishes that you need to fix and you can only discover them by using it and what a user will do is they will get frustrated and go away. Some will complain. Lots will complain. But by and large, you know, no one's just knocking down your door telling you all the little things. I mean, there's support for sure, but unless you're the builder and the building team that's using it. Once you're using it on the daily, you're not really going to discover the warts

or the real potential. You start to really, like, obsess and immerse. It's almost like method acting, you know? That's something about, like, in the moment. It's kind of like method developing, you know? To get some of the best characters we've seen on screen in Hollywood, some of these actors have had to go through life-altering scenarios where they will go so deep. Like Jim Carrey went so deep on a couple of different characters where he's just gone. I don't know if you've seen that recently, but there's a pretty interesting song up there that's popular now called Go from the Chemical Brothers. And it's pretty popular because of the movie Apex on Netflix with Charlize Theron and Egerton something or other. I forget what his full name is. I'm sorry, dude. But he played this character so well. Anyways, I'm sort of on a tangent here, but music was a really big deal there.

Where am I freaking going with this? Where I want to go with this is actually back to Asian experience. That's why I was trying to go with this, was to not get too lost. I know we're getting close to our time here. But, yeah, I feel like this space we're in right now, the way I think about things, I'm curious how you feel. And I feel like, yes, as of January, the table shifted. The whole world moved. And it's a new trajectory for almost literally everyone. Is now this idea that you're not really building the feature for the human kind of you are. You're doing it for human intent and human enjoyment. but the thing, the automation layer, the intelligence layer doing the work is the agent. And I've always known you as someone over all these years really is to be someone who really focuses on developer experience. And now we have agents and so we have agent experience, AX. And anytime I'm talking to my agents, I'm always like, you know,

this has to suit DX slash AX. And it's always including those sort of two labels there to justify my action to what I'm doing and the simplicity that I'm trying to think of. Like I really want this CLI to work this way for these reasons, and we have to have these kind of things in there not for the human really but for the agent who's using it so it can discover what this thing can do. So when you think about agent experience and Resend, and you have a whole entire blog post on this and all the good stuff, what is it that you think about when it comes to agent experience and building for agents these days? Oh, man, it's so hard because there are all these little things that I obsessed to get DX, right? So, for example, you go to the dashboard, you have these animated icons, right? So it gives you a sense of like, oh, okay, these people actually care. It's a little bit different than if you go to any other dashboard. Well, agents couldn't care less if your icon is animated or not.

I remember going on this huge project internally at Reason where every form that we had needed to have a keyboard shortcut. And you should be able to just submit using command, enter, and stuff. Man, I spent so much time with the team, and agents couldn't care less about that, too. They see the keyboard shortcut, they don't need it. So all these little things that you would imagine like, oh, they will help the agent, they don't necessarily translate to that. But there are many things that do translate. So if you care about your API and making sure you're respecting the HTTP verbs, you have an open API spec that's important, all that. But then there's a lot about discoverability, too. So what I found was, okay, we had an OpenAPI spec, and then I was asking my agent, like, oh, go fetch the recent OpenAPI spec.

And then it didn't know where to go. So I'm like, oh, no. Like, I actually need to – so then I went on this tangent of, like, how do I make sure that every time we have an OpenAPI spec update, we actually go to our website and trigger a CI job to update and add to the .wellknown folder. So those little things that you just discover by doing. And, yeah, I think it's the way to build these days. Like, you have to care about that. And it's a completely new discipline. Like, no one really knows what they're doing. Or if someone claims that they know how to solve for that, I would challenge that assumption. But you learn as you're going, right? Like, you try to get stuff done with your product. like we use this tool called 2027.dev where you give it an eval and then you try to do an action. So I try to do that for every single language, for example.

Like how can I make sure recent is easy for Python as well as for JavaScript developers as well as for Ruby developers. So then we have evals for different platforms. And then we try to see where do agents get stuck. Oh, do they get stuck here or there? how we can make sure they don't get stuck at these points. I remember adding a lot of copy page content as markdown so people can just paste on their agent of choice. We do have an agent that we ship in product, but many people, they just want to use theirs, right? They already have all the context there. So we try to make it easier that way. Like, oh, copy the logs as a JSON. I'm revisiting the error messages now because the error messages are crucial. Like if they're super generic, the agent gets stuck. So they know, okay, there's an error. Great. You want the agent to see the error and then try something else.

So like you have to think about what will be the next steps once the user gets this error. Like rate limits. Oh my gosh, we had to revisit rate limits because agents, they do way more requests than a normal human would do, right? So it's insane. Like, there's so many layers to this. Well, friends, this episode is brought to you by our friends at Coder.com, secure environments where developers and agents work in parallel. And I'm joined by Nicky Pike, field CTO for Coder. Nicky, what is a field CTO? So I get that question a lot, and it's, you know, half the people understand it, half the people don't. So a field CTO, I describe it very simply as we're DevRel for the C-suite. So we provide a bridge between the customer voice, between the C-suite and the managers and the leadership teams of our customers back into our product. And then we go through and we help enable our teams to have the same message to make sure that the message is correct and that we're building on something that people actually want, not just something that we think they want.

Okay, so we're taking the laptop away from the developer. Not really, though. We're putting them in a cloud development environment, a secure environment where they can work with their agents in parallel. These are blessed environments. What's wrong with the laptop? The laptop is the is the trap here. And not only because the fact that it could be stolen, you could lose it. It breaks and you're out of work while you're waiting for a new one. But there's also just the consistency that you got there. We all know developers. Developers are going to be looking for some of the latest and greatest. And if you're not really controlling how they get out there, that's where you get this. It works on my machine. It doesn't work in production. It doesn't work anywhere else because you don't have that consistency. You don't have that ability to really standardize what that environment looks like. And this is a problem not only for new people coming in. You know, the onboarding statement is average, I think, is like four to five weeks for a new employee to really get their local laptop set up and ready to start doing their first time of code. And, you know, the time to first commit is a metric that almost everybody knows. And the reason they can't do that is because there's a lot of tribal knowledge out there. They got to go talk to other developers. What are we using? Where do we get our dependencies? Are we getting them from public? Are we getting them from private repositories?

But there's also the security and the supply chain aspect of this. When you have local machines out there, look at like the Shai Halud, you know, that virus that went out not long ago. This was a compromise of the NPM public repositories. They went and downloaded things. NPM did what it did. Next thing you know, you're compromised. But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo. Those packages are expected to have been thoroughly vetted. We know that they're clean. Now, does this stop everything like Shai Haled? No. If that compromised package gets into your private repo you can still have that But it really reduces the surface area of the attack and it also reduces the blast area of the compromise should it happen because if your laptop gets compromised and you have to kill the laptop for whatever reason that's weeks out of work while you're either fixing that or you're getting a new laptop in. The cloud development environment allows you to kill that, start back up fresh, and you're back and running in five minutes.

You don't have to wait all that time. Well, friends, the first step is to go to Coder.com, install Coder, self-hosted environments for your teams to enjoy, to standardize around, and it's open source. So you can try it out today. Once again, Coder.com. That's a good point is this agent experience is not just crafting a good experience, but when you hit the hurdles and the bumps. course correction because that's when the turn will bound right now you'll come the agent will get stuck and come back to the the builder right and that their literal you know prompt and response loop or cues or loops or whatever is the fad these days right gets broken because resend errored and the agent doesn't feel like it has enough authority to make the the mutation change or whatever on their own.

They must get an operator or a builder's, you know, whoever's running the agent must get their approval to go forward again. But if your API, your MCP, your CLI responded in a way that was like, you know, you actually just hit a rate limit, and all you need to do is just pause for five minutes and your limit comes back or whatever the number is, then the agent's like, well, while that five minutes is going, one, I'll set a loop to have a background job work I can do, right? They'll actually write Python or a bash script and, like, prompt themselves because they've got some good feedback loop from something that they're using. They go and kind of, on the rest of the mission, they come back to that five minutes. They're like, great, resend's available again because the API limit's gone. They never had to go back to the user that's building with them to change that. They could have just sort of navigated around it or even learned a system. Like, the way you learn, like, even as humans, it's like learn by doing, right? but really learn by positive failing, right? And that's what agents kind of do with a CLI.

They just sort of like brute force a CLI or an MCP server and figure out what they can or they can't do. And I don't know if they really mean to be because they're not like cognitive, not yet at least, AGI, but they're not trying to hurt your servers or, you know, abuse your service. They're just trying to learn how they can use it. And so if along the way you have better milestones, waypoints, and just error responses, it's going to be a lot easier for that agent to get feedback from the system it's trying to learn while it's using it. So true. And, man, we've learned that lesson the hard way in the sense that the primitives are the most important thing that matters right now, like getting the primitives right. So what does that mean to you? Write that down. For example, the rate limits, you can just have a proprietary header to just like respond with the like where you are in terms of your rate limit.

Oh, you've used six of your temp requests so far. Great. So this is one thing. Like you go to many of these really like good services. They might use like a language that they have for themselves that they invented, right? Well, there's actually an RFC for rate limiting with three different headers, one for the count, one for the unit of time, and then one for when you should try again. You should follow that RFC because if you follow that RFC, agents will know. They will know how to auto-retry. So we had to go back to the basics, the CLI, the OAuth layer, the right headers, the right ATP verbs. More than ever, those things are crucial. And if you're trying to do something that's like, oh, a proprietary thing because you believe that you have a better opinion than others, like the agent will know what to do.

So, yeah, you need those. Like, for example, we always had, like, a YAML OpenAPI spec. And then I would use all these agent experience core services that are out there. There's so many. And because I'm unmarried about this, I keep, like, putting recent to see how recent we'll score. And then, like, two of them told me, like, oh, you don't have an OpenAPI spec. And then I saw, like, why? Like, we do. oh, they're searching for the .json version of the OpenAPI spec, not the .yaml. I'm like, ah, now I have to build a thing that converts from yaml to json, deploy it to the right place, so there is discoverability for that, and do it. Yeah, man, the primitives, oh, my gosh, that's the only thing that matters, like getting them as standardized as possible. Yeah. Yeah. What are any particular, I mean, you came up with the .md on the end of the URL,

so we didn't close the loop on resend.com slash pricing.md being a markdown render of that page. What other particular, I wouldn't call them tricks necessarily, maybe the things you're standardizing around that are like, okay, yeah, when we build a CLI, a CLI has to have these particular feature sets that serve an agent? Like, what are some things you're doing? Man, the CLI was one where I spent a lot. I'm glad you brought that up because I spent so much time on that one. I wanted the CLI to feel good for humans first. I knew that, okay, there's all this talk about agents. It's great. But if we want to show perceived value on the product, we've got to show it on the CLI as well. So the default way you have the interactive mode. It's beautiful with colors and different ways of inputting data. Just really, really cool. I love it. But we do need a non-interactive mode for every single command.

We should have different formatted outputs as well. So if you don't want like a plain text, that's not really, you cannot really massage that output, which we have like a JSON version of that. Then I remember like, okay, I remember shipping that JSON version. And then I saw how agents would always do like that pipe GQ command to extract data out of the output. and then ours was failing for, I don't really remember, like there was probably the way that JSON was formatted. I think it was a, oh, I remember now. We would return like the data or a possible error in an array or something and then it would always get confused. So then I changed the shape of the object of the output to make sure you could pipe the result. So just going over those things like, okay, how you can make your CLI actually good and then actually discoverable.

You've got to put in every single registry you can imagine. The updating system needs to be easy to use as well. Refresh tokens. And now like one area that we, going back to the importance of the primitives, we wanted to make off as easy as possible. So the permissions and the roles you've given the product, we just made it full access or sending only. As simple as possible, you can start your API key with only that. Guess what? Agents want things to be as granular as possible. Obviously, enterprises want as well, but users want that. So now we have to go back and rethink about permissioning and roles and scopes for OAuth tokens for API keys. So you cannot, every time you try to skip something and you're like, oh yeah, we can probably get away with this or we can simplify here. Think again.

Like, yeah, right. You know, it's hard. How much has this been a thorn in your side, so to speak, with like roles-based access controls? Like I know that you're a prior WorkOS employee and friend of Michael Greenwich, so I'm sure that you have just an unlimited account. I'm just kidding. Some sort of blessed way to just easily get WorkOS, right? WorkOS solves a lot of this to some degree. But WorkOS isn't for really everybody necessarily. Maybe it is. Maybe it's not. Like how do you handle this problem? Like it's not an enterprise problem. It's not a cross-the-chasm problem. It's an enabling that we don't want to have to build off, but also get it right for the future the agents demand from us. Yeah, it's really tricky. Like the build versus buy decision is always hard.

For the OAuth layer, for example, we consider using WorkOS. We ended up not because we felt like this specific part, we actually have to own it. But then there are other parts like the permissioning, the roles. I think we could use something. We're still exploring. We haven't solved that problem yet. But it's always a battle of like, what are the parts you own, right? So I have a friend, for example, who's building a really cool API platform solution where you can provision the API keys there. And I'm like, okay, this is awesome. But man, we are a company that we sell API keys to make money. They are a super important part of the business. I cannot just give that to someone else, and then that's another round trip. It's going to make it slower. If you're accessing the website in New Zealand, it might not be the best performance as if you're somewhere else. So you've got to think about all those things and then decide, like, okay,

yeah, this part we're actually going to bring, this part we actually need help. doesn't make any sense for us to build a completely new permissioning model. We're not here for that. But it should be extremely easy. The things we're not going to give up is like, man, it needs to be easy. It needs to be, yeah, like you should have those abstractions to make things more accessible for folks who don't have the time, who are trying to set up email on a Sunday afternoon while the kids are running. and they only have like 10 or 20 minutes. And if they don't get it right in those 10, 20 minutes, they're going to go away. They're never going to come back. You're not going to have another chance. Yeah. Do you have it where an agent can just discover or be told to discover, resend, and learn how to create an account? Like, does that exist today for you?

Account creation is tricky. So we haven't really, because of the free tier and the abuse vector that that would create. But we invest very heavily on like LLMs.txt, LLMs.txt. We had that in our docs forever, thanks to Mintlify. But then on our marketing website, we started to do that in every single page too. So you go to the most traditional marketing page you can think of and you put a .md there, like you get a friendly markdown version of that page. We haven't done that for every single page, but for the most part, like all the blogs, all the handbook articles, all the change logs. So the pages that we feel like they matter the most, content needs to be easily accessible, right? So we change, like, pages to have, like, an FAQ at the bottom of the page. That's the way people are asking questions. So let's try to make that a part of what we do.

Yeah, we did a lot of things. Like, we've been using Profound to detect the requests that are coming in. What are the citations? Okay, so let's figure out the citations because then that's how we can actually improve the quality of the response. What if, this is me thinking a lot because I love problems. I just love, seriously love problems. And as I'm listening to you, I'm thinking, like, what if when an agent signs up, they don't have, like, obviously you have the pricing still. It doesn't go away. And you still have your account structures because you can't remove that from, you know, your user orgs, projects, like, however you've mapped your world. But what if when an agent signs up, they can only sign up for a paid account? Like, what if that, I mean, because you have more agents now that have an email potentially because they're trying to get it or a credit card because there's somebody trying to crack that nut. But, like, what if, you know, I knew, like, hey, I know Resend, right?

I'm a user of Resend, and my agent, I want to automate this next package I'm building for my ecosystem, for example. and the package needs to send email or for some reason the agent needs to get a new resend account for that particular sliver. You don't know me, but I'm a trusted user. I'm a fan, and I'm down to pay. I'm ready to pay. I don't need to go through the whole just take my money. Just take my money. I love that. And, man, another big friction we have is, like, domains, for example. So we do require people to bring their domains to be able to send email. What if we just gave them a domain that they could just send from that? There are many deliverability constraints of that, but what if we did that, right, for the right people? I'm, like, super inspired by the outside world, right? Like, I love TSA PreCheck, and I love Global Entry, for example.

That's right. So, you know, those programs, you have to voluntarily pay for them, and you've got to show up for an interview. Guess what? After you do that, your life is completely different, right? Way different. It's like a cheat code that everybody can have, but nobody does. Oh, my gosh. It's the best thing ever. If you're listening to this and you live in the U.S., please get that thing. Pay whatever you have to pay to get it. It's like $300 or something. And, man, I love that concept of, like, you're coming in and you are voluntarily giving more information in order to unlock something else, right? Like an added benefit. So I've been thinking a lot about that, too. And that use case you described, I had that pain when this was, like, when I think Opus 4.8 got released. I'm like, oh, I've got to try this thing. And I went to YC. They have like this internal social channel there where you can go.

It's like their internal Facebook of some sorts. It's an internal community. Only founders can go, not even employees of YC companies. Only founders can go. So they really try to protect that place at all costs. But they have like a missing thing where you can push like information about your company. People can mark that they are using that. So people mark that they are using recent. They can give comments about how they're using recent. And I never get notifications about those comments. I would love to see it. Sometimes there's someone saying, oh, I had a hard time redeeming the coupon. Okay, then I can just fix that. So what I did was I gave my agent, like, go to Bookface and scan all the comments on this page every single day. Give me the sentiment so I can act on them. So I just set up that automation. This is me as a trusted user giving my agent access to do this one task for me. And then I go to bed.

Next morning, I wake up, an email from YC. hey, we're seeing that you're trying to scrape data out of YC. They look at the IPs and it was a mismatch between the IP that I logged in and this other IP. And then I get a warning like, hey, you've got to stop this or otherwise you're going to get banned for life. So I'm like, oh man. But that's just me trying to solve a problem with my agent. And I feel like services are simply not ready for that. Even recent to a certain degree is not ready for that, right? So we got to really rethink about how the extension of our agents. Like I was inviting five different users to our linear workspace, but they are not humans. They're agents, and I have to pay for an extra seat. Like seat-based pricing to me doesn't make any sense in this new age. I'm glad we've never did that with recent, but man, yeah. there's so many things we've got to rethink yeah that's the

that's kind of the fun part of it too right we get to rework a bunch of stuff and then thankfully the reason for doing it actually helps us make it easier because now code's gotten a lot easier to produce still you know still out there whether or not it's all good or not I don't know where are you at in terms of things are you 100% code generated in terms of you personally, corporately as Resend? Are you AI maximalists? Everyone can write whatever they want as long as it's with an agent. Not token maxing, but are you all for AI in every way to help Resend? Yeah, I think it's my job to be pushing that inside the company because it is a big unlock. and anyone who says it isn't, I don't know where they are living. I feel like it's a completely new world. I do hate the token maxing strategy,

but I love the rethink what you're doing strategy and see where AI fits into that, right? And I'm kind of like obsessed with the whole loops engineering or factory engineering thing right now. And I'm building, like, right now, I haven't even shared that with the team yet, but I'm building some of those loops that I feel like are closed loops. So there's one that I built that I'm using Cowork to do that, where it goes to all the downvotes on our in-app agent. It looks at those on PostHog, so it uses the PostHog MCP. Then it grabs that event. It looks at the whole session of the user. and then based on the whole session of the user, it sends a draft PR that updates the tool calls and the evals for that session to make it sure that, okay, the next session, this problem that happened right now doesn't happen again.

And then everyday people are seeing like this one PR that I'm sending and then sometimes they're good, sometimes they're pretty bad. And that's why I haven't really unleashed to the outside world yet. And I'm trying to imagine like what are those other mini factories that we could build, right? Like that we can close the loop. Maybe one agent is sending the PR, the other agent is reviewing. And we do that every single day or every single hour, every single minute. But it's crazy how we went through the whole journey of, okay, the bottleneck are developers. We've got to hire more engineers. Then the bottleneck is now PR. So we started sending a lot of PRs. Our repo used to have like 40 or 50 open PRs at any given time. Now it has 200. So, okay, it's a new volume of PRs that are being open every single time. Then the bottleneck became the review process.

And then we are like, okay, let's put AI on the PR. So we added Cubic, BugBot, all these bots. We tried, like, all of them. And then the bottleneck became the CI. Like, the jobs were failing or, like, taking forever to finish. And then, like, our compute was also, like, we didn't have enough compute. And then we had to change CIs. Man, the bottleneck keeps shifting, right? And it's fascinating to follow that. You've got to really, there's nothing you can do, right? You adopt the thing. If you ask me, do you miss that flow of coding, that moment of like it's you and your IDE, oh, my gosh, I do miss that. Yeah. What can you do? What can you do? Yeah, you can't fight entropy. It's going to happen. Wild stuff, yeah. A lot to dig into.

I'm sure we can go even further. I know we've got a few more minutes here. But one question I'd like to ask, especially whenever I feel like the person's got something up their sleeve, closer to the end of the show, is what's on the horizon? And maybe it could be something that no one knows that you can share here today, but it doesn't have to be. What's something on the horizon that's upcoming or recently released that just isn't getting enough awareness from you? What is that for you? What's on the horizon? and what's something that not many people know about that you can share? Yeah, it's hard to say one specific thing. And maybe what I will say is connected to that other point of like, you've got to be challenging the way you work every single day now. Unfortunately, it kind of sucks in a way because you're getting used to one way of working and now there's a whole new wave of things you've got to adapt and you start learning and figuring it out.

But things are moving so freaking fast that you've just got to challenge any assumption you might have. I'm challenging the assumption of who I am as a programmer, who I am as a CEO, as a founder, where do I deploy my energy, and it doesn't seem like there's... Like, in the past, I remember it was always like, oh, now I've got to learn a new JavaScript framework. Ah, it sucks. Like, I was just learning Ampere and now I have to learn Angular and now I'm just learning Angular and I have to learn React. And that sucks, right? Now it's like it has nothing to do with the framework. It has nothing to do with the technology itself. It's like the actual way of like how do you contribute? How do you add value? Where do you even spend your time?

How does that change your personal life? How you eat? How you sleep? Like it's just crazy, man. It's insane how you spend money. Like it's really, really crazy. so I would just encourage everyone to keep digging into their way of working and seeing like hey let me try this and then it's not good if it's not good right now then six months later it's good so assume that it will get better and if it will get better how would that change how you do work today yeah are you all hiring? Yes. I'm kind of hiring you doing these things. What is it like in two minutes? What is it like hiring today? The peaks and the valleys, and then specifically who you're trying to hire for? First of all, so much noise. Oh, my gosh. All these fake resumes and all these weird things going on.

But we are trying to assemble the Avengers of the email industry. Like we just hired like a guy that came from MailChimp that spent the last 10 years there working in deliverability. So we're like trying to find these people who want to challenge this industry and maybe feel like the place that they are at is not really the place. So a lot of email specific knowledge, but also if you're just a product engineer and you care about the work that you do, we're here for that too. work anywhere in the world? Yes. All remote. No, all remote. We don't have an office. We don't plan to have an office. Super small team, 45 people. Most of them have like engineer on the job title. Maybe 30 or 35 of them have engineer on the job title. We're very engineering focused and engineering driven.

Right on, right on. Well, as you know, I'm such a big fan of you and the work you've done. Still to this day, use Dracula. Still to this day. I really do. My Zed is so awesome because I have the plethora of, you know, from Van Helsing to Alucard, which I don't use too often, but every once in a while I've got to go to the light. but I think it's Mobius is my Van Helsing I believe is the one I use most frequently and Mobius I'm more of a dark mode and then the green mode dark mode too which the thing is if I recall it's Mobius if you're wrong yes it is Mobius big fan of that and you know so your little DX layers just delight my world every single day man Like, I really, and I'm thankful for subtle things like that, like subtle things like that that bring developer joy.

We haven't said the word developer joy in so long, right? Like, now it's agent experience and agent joy. Like, nah, man, like, I'm still looking at the screen. You know, I still have taste. I want to stay hacker to the heart and be in the terminal and not in some sort of, like, weird amalgamation of an IDE that's now an agent IDE. I don't know, an AI. I don't know. There's a lot of things happening out there, but I still appreciate subtle things like color. You know, really, I do, and I appreciate that. So for those of you who don't know, and this is buried in the lead here, is Zeno's the creator of the Dracula color framework. What do you call it a framework? Color palette. Color scheme. Color scheme. Yeah. Yeah. Is it Dracula.com do you own? Draculafiend.com. I've been trying to get Dracula.com forever, just like Xeno.com, but those things are hard to get, man. Yeah, Dracula might be the tough one, man. That might be a tough one, but DraculaTheme.com.

And you have Dracula Pro still gets out there, right? You can still purchase Dracula Pro, right? Or is it not paid anymore? Yeah. I'm being a big fan for all these times. Love what you're doing. Thank you so much for joining me on the show and sharing your depth and the world you're in. We could probably have gone deeper, further, longer, et cetera. But we'll leave it there for now, my friend. Thank you again so much for joining me. It's been good seeing you. Thank you, Adam. Thank you so much. You know, one of my favorite people out there is Zeno Rocha. I love the way he thinks. I love his energy. I love his excitement for everything. and yes, I'm going to be at Resend Forward this week talking to Taylor Otwell in the building room live on stage. If you're going to be there, come say hello. If you haven't heard, Resend launched inboxes. It is one of the coolest features out there. If you need to create inboxes to send email, they've got you covered. I'm building something on it. It's kind of cool. Of course, thanks to our friends over at fly.io for having our back.

Learn more at fly.io and of course, the Beat Freak in residence break master cylinder, bring those beats. That's it. The show's done. We'll see you in the next one. Winning. It really whips the whole thing. Yeah.