Building what's next (Changelog Interviews #687)
Show notes
This week I’m talking with Zeno Rocha, CEO of Resend, about scaling “boring” email to 3 million users, the secret Go rewrite behind it, and building for agents. We cover pricing.md, MCP, spam gangs, and why Resend keeps what’s next for email.
Changelog++ members save 10 minutes on this episode because they made the ads disappear. Join today!
Sponsors:
- WorkOS – Auth for CLI with AuthKit from WorkOS — Bring secure browser-based login to your terminal apps using the OAuth Device Flow, with the same polished AuthKit experience plus SSO, MFA, and passkeys. Learn more at WorkOS.com and AuthKit.com
- Buildkite – You deserve better CI. Buildkite is engineered for frontier scale and trusted by the teams setting the pace.
- Coder.com – Secure environments where devs and agents work in parallel. Open by design. Secure by default.
- Fly.io – The home of Changelog.com — Deploy your apps close to your users — global Anycast load-balancing, zero-configuration private networking, hardware isolation, and instant WireGuard VPN connections. Push-button deployments that scale to thousands of instances. Check out the speedrun to get started in minutes.
Featuring:
Show Notes:
Something missing or broken? PRs welcome!
What's up, friends? Welcome back. This is the changelog. You know what? AI agents, they cannot drag a pricing slider.
That's how Zenorosha found out that Claude and ChatGPT were both telling people re ReSend was the most expensive email service on the market, which is not true. And the fix was simple. It was a markdown 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.
Shortcuts. We also get into publishing your open API spec as JSON in the dot well known folder so tools can actually find it, why agents demand granular API permissions, and the closed loop system he's building turns down votes on Resend's in app agent into draft PRs. It's a whole new world. And speaking of a whole new world, I'm gonna be live on stage at Resend Forward on October 21, this Wednesday, talking to Taylor Otwell live on stage in the Builder Room. Learn more at resend.com/forward.
Alright. Let's do this. Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of Work OS. Michael, author agents. I feel like this is burgeoning.
It's it's kinda happening all of a sudden. What's the state of the world for author agents?
Yeah. It feels like author agents is 1 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 2 things here. The 1st is when you say author 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 WorkWest Pipes. It's actually more of an integrations product. It helps you take your agent and connect it to your customer's Google Drive and connect Salesforce and HubSpot and connect it to Slack and all this other stuff that they're gonna use and do it in a way that's safe and secure and managed. That's 1 type of auth for agents, kind of data access auth. The other type is actually authorization.
It's like permissions for what the agent is going to go do. Because you connect it to 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 3rd, I would say, is probably the identity layer for agents. How do I identify an agent by its name? You know, that's really coming from the enterprise identity systems that are out there. If you look at Microsoft and Microsoft's Microsoft's Entra 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, Workflow is a great place place to go, but it's changing really quickly. You know? None of us were talking about OpenClaw, you know, like weeks or months ago. And that's a new paradigm I think we're gonna see not just within consumer software but in the in the enterprise too.
So it's a... It's an area of very, very rapid development.
Well, it makes me think about agents versus people, not negatively, but this world where we'll have more agents than people.
You know, today, we have 7 or 8,000,000,000 people on the planet, in the future, we're gonna 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 gonna 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 with it. So we're building for that future today.
Alright, 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. 1000000 users with Authkit for free. You can't beat that deal. It's it's literally free. Again, workos.com.
Try it out today. My friends, we're back with my long time dear friend, Zenarocha, a 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 wanna discount that because I know you're a proud father and
and husband.
But at the same time, a very successful founder and CEO of Resend. Everyone uses Resend. Is that... That's the best. Right?
Yeah. It it... We care about email more than others.
That's how
I I describe
mean, when I 1st... If I'm being a little honest, when I 1st 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, kinda 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 email 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 how usage based businesses also grow over time. And if you go after a big audience, 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...
I I... And I'm 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 1 time.
Like Wow. Pretty crazy email conference. Like, only, like, the people who are running the spam filters at Yahoo and Outlook. Like, it's just like... It's a crazy world.
And... But, man, I believe those boring businesses, those ideas that seem extremely like, oh, why do we need another 1 of these things? We already have so many different email services, right? And I just saw, yeah, 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. 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 1 or 2 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 could tell that you're a developer, obviously, with... And I don't know how much you played a key role in in your CLI and even the commands and the way it composes, but just resend emails, send is... And the way that composes from the from, the to, and the subject, and the body, of course, is the the way it composes is 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 Braintree 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 kinda boring. Still is kinda boring, except for exciting to make some money. Right? But they took this this already had been done thing and global player.
Well, you know, the 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.
Mhmm.
1 of the 1st landing pages from Stripe had this tagline, payment for developers. And that's the tagline we used at recent, email for developers. It's simple as that. Like, 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 Right.
Think about all the different industries where you don't have us.
Right? Doesn't block trash. I mean, Square is like the best also ran, you know, in a in a good way. I mean, I love a lot of folks at Square. I've got some friends at Square, but...
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 in also ran in kind of a way, but they've also just, like, dominated it in good ways too, but now they're being dominated at the hardware level, like the Clover and... I I can think of, like, 2 or 3 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 gonna 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 doesn't hook some collaborations, but I'm not sure of anything in particular like like Square has Square Terminal, for example. I don't know.
Is there
a Stripe terminal? I mean, maybe
Yeah.
A a digital layer, you know, maybe a software layer.
I think the beauty of Stripe is, like, they solve 1 problem, and they get that 1 problem, and they solve a different abstraction layers. Right? So when I think about my own journey as a as a Stripe user with Recent, we started. It was, like, January 2023, and y c batch was kicking off. Right?
So I was, like, stressed out. Oh my gosh. What am I gonna 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 did... I barely had a product, and now, like, you know, integrating payments, 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'd tell my friend or whoever introduced me to that person.
So like, okay. So what do you think? Do you wanna try it out? And they're like, I don't know. I was like, no.
No. You should 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 the... 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 gonna scale.
We need something in the product. So then we embedded those widgets that they have. So that was great. And then once the... You know, we got 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, 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. Talk
me 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... You know, how... 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, like, deciding where are we gonna 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, k, 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 TeoWind, TypeScript, and React. Right? 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 1st world, not an API 1st world? Truly believe that. So...
Okay. Then we invested super heavily on the Node SDK, but also SDKs for dot net, Rust, languages that would be maybe not as used because they were either too boring or too new. So we built those. And then we have the actual service. Right?
Okay, we're going to run this thing. How are 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 the the hottest deployment platform.
We chose the hottest database platform. And we 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 looking into either building more of that internally, others not as much. We did rely on SCS, 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 1 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, pretty exciting.
But, yeah, that's life at a startup. Like, you choose a stack. It serves you well at a certain Maybe then you gotta move. But there are other parts that that, you know, we still use and love and so on.
Are you involved in 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, the fire broke out, you had to step in and do something, you'd probably fire up Claude, maybe it's Codex, you know Mhmm.
Whatever. Maybe your hand coding's 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 we use CDK a lot. So in the beginning, it was all ClickOps, like, 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 a good way. A lot of our system was not designed as a... Like, everything was synchronous, and then we... 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 on an email, when you open an email, we fire those events through SNS. We use Datadog ex... Like, so heavily. It's definitely...
Like all the other startups out there, it's probably 1 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 Vercel in other places too. So our dashboard, our marketing website runs on Vercel.
We try to use TypeScript everywhere. And I was holding that fort for the longest time. 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 1 piece of the infrastructure, which is the actual pipe when we're sending the the emails.
And we rewrote that in Go recently, like 3 or or 4 months ago. So those parts are way more Mhmm. Scalable right now. And and... But it's all very modular now.
And...
Yeah. Can you share some details about that that Go rewrite? Like, what was involved? Like, what does the pipe do? Why why was Go...
Why did Go make more sense? Was it probably the the binary? Right? The 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 there are 2 different ways of sending email at resend. There's 1 where you call the API or send in 1 email, you just go. 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. 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, This is weird. Like, why are sending all that volume all at once? Right? So what every single email platform out there, and 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 3,000,000, we need to space those out so that you're not going to be throttled 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. I'm not going to place them on the inbox right away.
Let me see the 1st ones, and depending on that, I might move them to the right place. So that part was really tricky because you have 1 customer sending 5,000,000 emails, but then you have, I don't know, dozens or hundreds of customers sending 5,000,000, 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 and Go is 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 the platform understands how to shape things to your SNS partners, etcetera? How do you think of...
How do you... How 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, they're like, oh, it sucks that I have to wait 4 hours for all my emails to be sent. 3,000,000 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 depends on the shape of how many emails you're sending in the past. That also... That...
That's also important. So there's a lot of little things that we might do to improve your deliverability that if you if you were to just, like, move them and and send to those inbox providers, they would just either throttle your sending, which is what Gmail does very often, or send straight to the spam folder.
When you fit this this Go application in, how how did you have to re... 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 the swap? And have you swapped?
Did you swap it over yet?
Yeah. We did. We had multiple false starts. Like, we would go... 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, like, 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.
Like, no 1 knew this was happening. We haven't even talked about it publicly. This is the 1st time that I'm Wow. I'm actually, know, saying, oh, we use Go at recent, you know?
Nice. I'm a fan of Go. You know, I think about my thought matrix when it comes to languages, the 1st thing I wanna 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 sorta have to you have to embrace TypeScript.
And the the agent, the model doesn't really need the types, but what it does, you know, enjoy, I suppose, maybe 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... It... The the agent doesn't need to remember the types, but it does need that system to remain sort of, like, guardrailed so it doesn't have to do these wrong things or the
right
things. And so I try to choose TypeScript 1st, but I find that more often than not, the better shape for almost everything I wanna 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 BUN 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.
You know, like, once you get past the system, the API, you know, all those things as long running services, you kind of... I mean, there is web stuff there, but nowhere near, obviously, the the world of JavaScript, which is kind of a bummer. I almost wish that TypeScript and Go would just somehow merge, but maybe not. Maybe not. I I know we want 1 choice, but it is...
It's a beautiful world we're in now where we can choose more than 1 language, and we don't have to be TypeScript for life as you may have been in the past.
Jordy. And, like, I wish there was a Next. Js for for Go. Right? Like...
Or even, like, an Express for Go. You obviously have a big ecosystem there, but there's there's something lacking when it comes to the web, like you mentioned. But, yeah, it's just beautiful, like, the idea of, like, k, 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. Mhmm.
Obviously, there's some work to 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 Xoft 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 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 a layer in between them or something like that. But there was definitely some work, even 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? 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 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 a little bit tricky. Test suites, another 1 too.
Yeah. Well, 3,000,000 users is a big deal. Last month is a big announcement. I think it was, like, 6 months before that, you were at 1000000. So, obviously, you're growing fast.
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 kinda 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 I thought it was kinda funny in a way that here in 2026, you would announce an official CLI as if, like, that wouldn't have been, like
Big deal.
Step 1. You know? Like, honestly Yeah. I I couldn't deliver, build, or operate a service unless it has a CLI. So I'm 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,000,000 users, this new agentic era official CLI. What's what's the nugget in there we could 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 building my own little apps. But more than that, the entire infrastructure as a service category, I would say, benefited from what happened.
So recent is growing a ton, but we're not the only ones. The companies who are being suggested by Claude, suggested by OpenAI, they are riding that wave same way as we are. And it turns out, once you have those integration points, 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, the... I see people and I I see myself using Cloud co... Cloud CoWork as my operation system.
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 I need an MCP server. I need a CLI. Like, there's no no negotiation.
Like, I I would just move to something else.
Yeah. Yeah. I feel like which is kind of the the comical thing here is here we're in 2026 officially having a rescind CLI. What took you so long? You
know, like Yeah.
Were you just too busy? What... Like, I know in 3 years time, you got so much to do, but, like, seriously, why did it take you to this year when the boom happens to make an official CLI? Like, why why the gap there?
That's a great point. We 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 transactional emails, reset password, welcome emails, whatever you need to send, right, usage emails. But would someone go and 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. 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 1. 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 open API spec. It would generate a super poorly written CLI based on that. And I just hated that. So we're like, no, let's actually build 1.
We chose TypeScript for that 1 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 builds 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 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 on your headers. You're good to go. Now 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 ship 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. They they... 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 added we started with transactional, then we added marketing. Then people asked for a way to receive emails, so we added that. And then they asked for automation, so we added that. So you 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? Like, of this list, the things that really stand out to me is, like, receiving an email, broadcasts, and automations. But that's just my... That's my take.
Yeah. Receiving is tricky because, 1st, just the setup can be tricky. You you add an MX record, but then if folks use Google Workspace, now there's a competition between the priority of the MX record, so you've got to deal with that. You've to teach users how to deal with that once there's a conflict. So that was 1 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. Yes. And they don't even know, oh, my emails are not... You know?
Not
sad getting too. It's like 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, like, these wildcard usernames, like, support at whatever, security at whatever, sales at whatever. So you gotta do with that too.
And you're just like, you're walking around out there in the marketplace, Zeno, with this target on your back, basically. You know? Like, just take us down. We're dealing with the hardest problem here, 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 1st... Like, even for the 1st thing the user needs, like, what do they need?
Do they set up an email inbox? Do you automate it 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 the 1st thing is like, man, I gotta 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 are like, okay, looking for use cases internally that we will be able to receive emails, triage them out of mage, like, okay, based on a support message. Let's not necessarily reply, but draft a reply for our 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... 1st of all, users were crazy about this.
This was our number 1 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 1, the frequency was just so freaking high. So we're like, okay. It's it's an obvious problem. People want us to solve that problem.
Let's go try to 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, like, 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 going with... Picking 3 or 4 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 were in 5 or something.
And then we just kept building that v 0 of inbound. And the reason why I love doing that is because you have to make so many trade offs as you're getting started. And you're in the room, 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 as you're building as well. And then you uncover all the the... Now you 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 I love going... I I gotta 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 a... I'm special. It's just because I won't have the empathy. I need to have... I need to feel like, oh, this sucks.
This sucks so bad. And I go through, like, Dracula, and I'm like... That's why I'm like, no. I I go to my Dracula domain, which I do use a Google Workspace. I'm like, and now I have to configure the DNS set...
This DNS settings. Okay. But... Oh, the conflict. Oh, what do I do now?
Like, I'm lost. Like, how how do I overcome this? So that's why I love having side projects Yeah. Until now because I can always use them to feel that empathy.
Is this mainly giving... I don't want to say, like, an agent. We've set an application in the past, but feel like now our application layer kinda 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 use?
Like, what was that pain you mentioned?
Yeah. There are many use cases with inbound. So there's 1 company that we help them. They do trip management. It's called Tripsi.
Amazing app, by the way. You should definitely check it out. It's beautiful. 1 of the most beautiful iOS apps I've used. And what happens with them is like, oh, I 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 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 1 use case, and it's a use case that I I like a lot. You're forwarding a PDF.
You're forwarding whatever you want, like... Or a CRM where you are adding a BCC, and that 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 b to b. But then you have the b to c type of use case where I'm setting up my OpenCLI, I need it to have an inbox. And I just...
I 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 as much, but still a pain. So so it's hard because we're trying to solve the problem for both. There's the wildcard 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 inbox UI for you to interact. And, obviously, this will...
UI will come with its own CLI and MCP server.
Well, friends, I'm here with the CTO of BuildKite, and 1 of the most challenging problems of modern era software development is continuous integration and continuous delivery. And so Lachlan Donald, BuildKite 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 are asking us at the minute, like, you know, if we've 5 or 10 x our throughput this year or 1000 x it, what breaks and when? And, you know, my answer is kinda same as it's been for the past 20 years, which is the 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 are the same, but we're just 1000 x ing the speed of it and, you know, that changes nearly every variable.
Yeah. For sure. Okay. So where where does BuildKite thrive? What particular type of team or enterprise do you thrive in?
The area that BuildKite has always thrived in is is like this, like, fastest moving tech companies of the world. It's like we've been disproportionately successful in that small niche. The kind of Shopify class, Uber class, you know, OpenAI class of folks that have this key problem around iterating really, really fast. And, you know, the the thing about all of 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 puts our system in this tension where, you know, you've gotta spend some time assembling those building blocks, the... 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 Lego blocks and then are kinda working backwards towards kinda creating the thing that scales down to a startup that starts with 1 person and 10 agents next week.
Well, friends go to buildkite.com. That's buildkite, kite.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, like, an agent like Open Claw, for example, how close did you come to identity? Did you teeter it all around anything where now... Because... Because I was actually thinking about this recently.
Like, here in The United States, 1 of the ways you define your societal identity, like, Mhmm. 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... We're just doing, you know... For, you know, for all the reasons why it's fine.
It's fine. They ask you this. Mhmm. What do you hand them? You don't hand them...
Maybe you hand them your hand if they're gonna take a fingerprint. That's weird. Mhmm. 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 handed 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 Mhmm.
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 I actually thought a lot about that, and we obviously had the news this morning about Beta Of being acquired by Vercel, 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. So to me, Posthog is brilliant because they saw something that no 1 saw. Like, I was using Mixpanel and those tools forever, right?
Like Amplitude, like, for product analytics. Never I thought about putting feature flags and product analytics in the same product. But they are JSON. Right? Once you have those events, now you gotta figure out what to do with them and then...
So that connection of, like, 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 a lot to our users to understand, like, okay. Before use recent, okay.
Maybe I'm doing this, and then I do that. Great. So identity is 1 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 I I haven't made that brilliant connection that, oh my gosh, now it makes so much sense. It could be background jobs because no 1 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 they're outside of the critical path. 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,000,000 users are asking for so many things here. I'll just stay in our lane, at least for 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,000,000 users are probably pretty, to some degree, vocal. I'm sure there's at least 0.333, you know, maybe 0.25 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 kinda you kinda should listen. Right? And so are they saying, I want identity with my email?
Like, what are some of the things that they're really pushing you towards when it comes to product?
I hear a lot, like, phrases like, oh, I want a a reason for a WhatsApp, a reason for SMS. Twilio sucks. Can you please make my life a little bit better? You know? You know, And 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 1 channel, but I'm just trying to get to users.
It's a comms channel, really. Right? Like a comms It's a comms. Gateway. They want they want 1 place to go, 1 API to call, 1 dashboard to look up, 1 log to reason, etcetera.
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 turn left. Like, it's crazy how deep email goes.
It's insane. I'm always amazed at, like, how much there is to build still. Like, I'm sure... Like, we have a roadmap for the next 10 years easily. Like, even if we just stop paying attention to everything, there's 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, many agents.
So, technically, it's an agent. You know, what are 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 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 a new for a company.
Like, the moment we had our 1st downtime, I knew very quickly, like, okay. This is a different type of business.
Yeah. Now you're you're utility now. Yes.
If I
call you, they expect you to answer quickly every time.
Exactly. Every time. That's utility.
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, it's okay. I'm just sending a marketing email. It's fine. For others, like, no.
My u... 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 a big success team. My big, I'm talking 5 people. But, like, we are, like, trying to be spread in as many continent as possible. We now have people in 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 wanna ask you this question with a negative, but I'm gonna do it Mhmm. Just to get a reaction and just to to dive in a little further. But, like, is 3,000,000 users a lot? Is that a lot?
I know it's a lot when you go from 0 when you have 0 stranger... 0 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 agent experience.
Is 3 main a lot? Is that a lot?
Yeah. That's a that's a good provocation. I saw recently that Supabase had crossed, like, 10,000,000 users. That got me thinking, like, oh, is this the TAM for developers? Is that Mhmm.
How big it can be? I forgot now, but on the the Twilio website, 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? You... I... Crazy story, man.
I was at Vercel ship last week in New York City. And, you know, as 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 the vibes in the the audience. There's a lot of VPs and CTOs and CMOs, And all that kind of 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 Resend. I don't use Raisele yet. It's too complicated, but I I use these tools, and it's great.
Was like, man. That was so special to hear. And I'm just reminded... This was, like, I don't know, 6 days ago. I'm reminded about the people who we're serving.
We do have email for developers as a tagline. We have so many designers, so many, I don't know, product managers, marketers using recent, 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,000,000. You know? Like... 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 I observed that already by answering the tickets.
They just say, my email is not working. The 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 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 I don't think 3,000,000 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 gonna mention his website. I was I was looking at my phone right now.
If you saw me looking away for a moment, I was trying to think because
Mhmm.
A good friend of mine, Hamilton Heald, he and his wife started this 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, you know, like with you after lunch and this fella.
You know, it's not that they shouldn't, it's that it's peculiar now. It's the new it's the new new. Right? And my buddy Hamilton is a smart fellow, but he's not a software guy. He's not a technologist necessarily.
He's inclined. He's not foolish, but he... He's not really a developer like you would consider 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, like, you got these folks now that are using services. The way I tell people like this is, like, with an API key, even. Like, to use resend, you have to use your r e underscore API key. Right?
Like, you're gonna get this API key, and that's like your driver's license in a way. And that... In this case, maybe it's your ability to access something. Don't know. It's a key.
Mhmm. It's it's so interesting in this world. Like, it's... To explain what an API key is to people, I don't know what you're talking about. What does that mean?
Well, it's just a key. Like, you take your keys out and you say this is a key. This is a a digital version of that same concept, and it's got the certain grooves and, you know, cryptography that's basically physical cryptography cryptography, which is like the shape of a key, for example. And 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 o auth 2 application inside the dashboard.
Like, 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. You know, in the case of where you charge per user, for example, you wanna 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 Mhmm. 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 and these services in this whole new world, and it's it's kinda wild and exciting at the same time because my buddy building a service and his website, I said, what? And he showed up to me. I was like, dude, this is good.
Like, this is good stuff, man. Like, it's not vibed at all, but 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. Like, that's wild.
So he's 1 of 300... 1 of 3,000,000. 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 1 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.
We have a big challenge in, okay, we want to make it as easy as possible. Great. 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 Nonstop.
It's a different... Nonstop. It's a different version of that too. Maybe last time, if we even talked about that subject. No.
Maybe, like, a couple people coming in recurring. Now we're talking, like, full gangs. Like, they are spam gangs. They have, like, thousands of domains. I'm not talking 10 10, 20, a 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 the... To this thing.
So Wow.
That's interesting. Make it easy. Yeah. But it's so tricky. Like, for example, account provisioning.
Let's say you just wanna do that programmatically. You wanna hit an API to even create an a... To create an a... An account to be able to create an API key. Those are the things I 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 a bot detection at 1st on the sign up page. I'm like, no. I'm removing this thing. This is not gonna be here anymore.
So I just rip it off. I rip it off. This was like a Saturday afternoon. I lip... I I rip it off, and I'm like, no.
We're gonna have bot detection on the login, but not on the sign up. And then you try to make things easier, but, yeah, it's it's it's hard. But then you'll see... You'll hear those stories and, oh my gosh. It's just beautiful, the the power of, you know, these models these days and and people with great ideas can just make them happen.
Yeah. You bring up a good subject, which is the free tier, and I know that you have a free tier. So you got a 0 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 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 it's hard. I think we were just... Like, we just invest so heavily in in that anti abuse program internally. We have so many systems that we're building.
You 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, okay. Think of, like, crazy ideas, go insane, moonshots, how we can make this 1 part of the company easier. And for trust and safety, 1 of the moonshots was like, oh, let's kill the free tier.
In 1 2nd, we're gonna 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. 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, I was able to get started with that.
And then 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 1st place. So to me, like, there's no way we're gonna 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. In fact, just today, this morning, we crossed 100,000 paying customers.
So 3,000,000 users total, 100,000 paying customers. And it's just like if you have the right incentives, the right levers at the right places, 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 1 tier to the other. But they are still generous enough.
Right? Like, it's 100 emails per day. If you're sending over a 100 emails per day, okay. Maybe you have something going on. So then, k, now you can pay $20.
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 it's a dual thing. It's 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 1st 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 and and take, like, 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, like, 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, v 0, man, those guys, they were driving so many sign ups to resend. But our revenue was just, like, growing the same way. January 2026, completely different because Claude, OpenAI, they were 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, it really is. I mean, you can scrutinize. It's almost like long term thinking versus short term thinking. Right?
Your short term thinking is like, oh, free tier is bad. Long term thinking is like, no. Actually, tier is really good. You just gotta get past the pain of it. You gotta, like, look at it as a nonburden 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. Like, how much time do you personally, as CEO, think about free pro scale enterprise? Like, is it on the daily? Is it once per week? How do you think about your tiers?
Oh, man. I I think about them all the time. And not not daily for sure, but I see people like... So for example, because we have those levers to help people transition from 1 plan to the other, people are always complaining about those levers. Right?
So in the free plan, it's like 1 domain. And people are like, oh, I can't use recent because it's only 1 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 1 thing and then you lose the other part. So if...
I think about pricing a lot and positioning too. Right? So we could have, like, a cheaper 1st 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 you you change that too? Right?
So we... We're trying to position recent as this premium product, prominent... 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.
Like, I think we got it right with transactional emails. With marketing, we charge per contact. And in in this age where you launch an app and now you have 1000000 users out of nowhere, like, pricing per 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 gonna innovate in pricing. Let's just mirror what our competitors do. Right. I feel like that's a great idea at 1st, 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 accessed 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 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'd want on a pricing page. I'm not sure what what role you personally played in this, but the slider of helping you choose which tier, like, people wanna know not just what do you offer and how can I pay you to get what you offer, which is the 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? Or, you know, pick whatever metric you're comparing against. Then obviously, you're gonna always have that enterprise tier on the far right hand side. I feel so bad for those enterprise folks.
Always in the far right. You know? But then you've got this slide 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 know, you're not selling with, like, probables.
If this could probably happen or these... You know, this is exactly what you're gonna do. Like, if you're gonna stand in the 500,000 range, probably gonna be in the scale territory. And to me, that's really cool, like, how you've designed this page. But how do you see this page changing?
I know that... I I can't recall what it was. I think I saw you do this where you just added a dot m d to the end of things. I think... Did you start this movement?
He said, no. I think this is you. Right? So how how much traffic is this page getting that is nonhuman now that's still influential, and how do you influence influence the nonhumans? You know, 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 is good, but it's good for humans. It's not Right. It's it's terrible for agents.
It's... Yeah. It says not... Well, mean, maybe operably, like, 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 right pricing?
Well, tell me what your payload might 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 and all that is maybe an API call and the response is j JSON. It's like, here you go. This... Or maybe it's market.
Maybe it's actually markdown. I don't know. But anyways...
To... No. Totally. And we... The way I found out about that was again, Saturday afternoon, I'm just tinkering with stuff And then I asked, like, oh, I was creating maybe a competitor analysis on Clot 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 I was, like, so surprised, and both of them got it wrong. And then I was like, okay. Let me uncover this. So turns out that agents don't really like JavaScript enabled sliders. They cannot slide.
That's not something they're they're able to do. And I'm like, okay. We need a a markdown version. So I made the markdown. I changed the 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, see in for real life. And then I just made the request and then started to get the math math right. Like, all... So what I did was, okay.
I'm sending 3... Or 2,300,000 emails a month. How much would I pay with resend? And then it would get the number wrong, and then I was, like, pushing changes. I was like, oh, maybe update the copy.
Let me update this. 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. So in the end, it's like you you...
If you're not playing with your own products or if you're not, like, putting yourself in the shoes of the users as they're considering your your product, then, yeah, like, it will be impossible to uncover those things. Like, no 1 came to me and said, like, oh, your pricing is wrong or my agent is telling 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 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 every team goes in, they write their updates, and then we go through that doc together and and that's it.
So, like, 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 like that 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 1. It's always on the 1st 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 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 it on the investor update.
And I I just keep inventing those excuses. Like, right after this call, I do need to send an email for Dracula. We already have the draft done, and I'll just go ahead and and send it. So I'm always, like, coming up with whatever reason I can to, yeah, to to use the product. Mhmm.
That's cool, man. I feel like that's that's definitely the way you uncover the 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 that's using it, unless you're using on the daily, you're not really gonna discover the the warts or the the real potential. You know, you start to really, like, obsess and immerse.
It's almost like method acting. You know? It's it's something about, like, in the moment. It's, like, kinda like method developing. You know?
You... 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, like, a couple of different characters where he just, like, just just gone. You know? I don't know if you've seen that recently, but there's a 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 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 a really big deal there.
Where am I freaking going with this? Where I wanna go with this is actually back to Asian experience. That's why was trying to go with this, was 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... And I'm curious how you feel.
And I feel like, yes, as of January, the 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 you're doing it for human intent and human enjoyment, but the 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, know, this has to suit d x slash a x, and it's always including those sort of 2 labels there to justify my actions and 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 and you have a whole entire blog post on this and and all that good stuff, like, 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 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, k. These people actually care. It's a little bit different when you... 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 Recent where every form that we had needed to have a keyboard shortcut. And you should be able to just, like, submit using command, enter, and stuff. Man, I spent so much time with the team and agents couldn't care less about that too. Like, they they see the keyboard shortcut. They don't need it.
So all these little things that you 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 ATP verbs, to have an open a p... OpenAPI 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 it didn't know where to go. So I'm like, oh, no.
Like, I actually need to... The... So then I 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 dot well known folder. So those little things that you just discover by 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 1 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 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 it 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 for different platforms. And then we try to see where do agents get stuck. Oh, is it... 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, like, copy page content as markdown so people can just space on on their agent of choice. Like, we do have an agent that we ship in product, but maybe... Many people, they just wanna 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 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 it's insane. Like 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 Nikki Pike, field CTO for Coder. Nikki, what is a field CTO?
So I get that question a lot and it's, you know, 0.5 the people understand it, 0.5 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 the c suite and the 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 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 1, but there's also just the consistency that you got there. We all know developers. Developers are gonna 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 on... 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 4 to 5 weeks for a new employee to really get their their local laptop set up and ready to start doing their 1st time of code. And, you know, the time to 1st 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 gotta 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... 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 Hulad?
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 environments allows you to kill that, start back up fresh, and you're back and running in in in 5 minutes. You don't have to wait all that time.
Well, friends, the 1st 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 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? 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 a builder's... You know, whoever's running the agent, they 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 for 5 minutes and your limit comes back or whatever the number is, then the agent's like, well, while that 5 minutes is going, 1, I'll set a loop So I have a background job work I could 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 5 minutes. They're like, great. Resend's available again because the the EPI limit is gone.
Like, they they never had to go back to the user that's building with them to to change that. They could've just... They just sort of navigated around it or even learned a system. Like, the way you learn, like, even as humans is, like, learn by doing. Right?
But, really, learn by positive failing. Right? And that's what agents gonna do with the CLI. They're 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 gonna be a lot easier for that that agent to get feedback from the system it's trying to learn while it's using it.
So true. And, man, we... We've learned that lesson the hard way in the sense that the primitives are mow... 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 the... Your rate limit. Oh, you've used 6 of your 10 requests so far.
Great. So that... This is 1 thing. Like, you you go to many of these really, like, good services. They they might use, like, a language that they they have for themselves that they invented.
Right?
Mhmm.
Well, there's actually an RFC for rate limiting with 3 different headers. 1 for the count, 1 for the the unit of time, and then 1 for when you should try again. You should follow that RFC because if you follow the 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 the right headers, the right ATP verbs. More than ever, those things are are crucial. And if you're trying to do something that's like, oh, a proprietary thing because you you believe that you have a better opinion than others, like, the agent won't know what to do. So, yeah, you you need those... Like, for example, I we all always had, like, a YAML open API spec, and then I would use all these agent experience score services that are out there.
There's so many. And because I'm a nerd about this, I keep, like, putting recent to see how recent will score. And then, like, 2 of them told 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 dot JSON version of the OpenAPI spec, not the dot YAML. I'm like, ah, now I have to build a thing that converts from YAML to JSON, deploy to the right place so there is observe... Discoverability for that and then do it. Yeah. I mean, the primitives, oh my gosh.
That's the only thing that matters. Like, getting them as standardized as possible.
Yeah. What are any particular... I mean, I know you came up with the, you know, .md on the end of a URL, so we didn't close the loop on resend.com/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 just 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 1 where I spent a lot... I'm I'm glad you brought that up because I spent so much time with that 1. I wanted the CLI to feel good for humans 1st. I knew that, okay. There's all this talk about agents.
That's great. But if we wanna show perceived value on the product, we gotta show it on the CLI as well. So the default way, 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 format... Formatted outputs as well. So if you don't want, like, a plain text that's not really...
You cannot really massage that output. We we have, like, a a JSON version of that. And then I remember, like, okay. I I remember shipping that JSON version, and then I saw how agents would always do, like, that pipe g q command to extract data out of the 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 in an array or something, and then it will always get confused.
So then I 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 gotta put in every single registry you can imagine. The updating system needs to be easy to use as well. Refresh tokens.
And and now, like, 1 area that we 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'd give in 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 and roles and 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 of 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 unlimited account. I'm just kidding. And some sort of 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 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 crossing the chasm problem. It's a... It's an enabling that we don't wanna have to build off, but also get it right for the the future that agents demand from us.
Yeah. It's really tricky. Like, the 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 if this specific part, we actually have to own it.
But then there are other parts like the the permissioning, the 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 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 for...
You know, to make money. Like, they are super important part of the business. I cannot just give that to someone else, and then that's another round trip. It's gonna make it slower if you're accessing the website, and New Zealand might not be the best performance as if you're somewhere else. So you gotta think about all those things and then decide, like, okay.
Yeah. This part, we're actually gonna bring. This part, we actually need help. It 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 gonna give up is, man, it needs to be easy. It needs to be... Yeah. Like, you 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 their 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 gonna go away. They're never gonna come back. You're not gonna, you know, you're not gonna 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, was... 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. Full.
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 dot m d there, like, get a 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 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. We we...
Yeah. We 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 the quality of the response.
What if... This is just me thinking out loud because I love problems. And let's love... Seriously love... I 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, the... You... Obviously, you have the pricing still yet that 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 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 I wanna automate this next this next package I'm building from 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.
I... You know, you don't know me, but I'm a trusted user. I'm a fan, and I'm I'm down to pay. I'm ready to pay. I don't need to go through the whole, just take me to...
Like, just take my money. Does that know? Right? 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 we did that, right, for the right people?
I'm, like, super inspired by the outside world. Right? Like, where I I 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 gotta show up for an interview. But 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 US, please get that thing. Pay whatever you have to pay to get it. It's, like, $300 or something. 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 gotta try this thing. And I went to YC. They have, like, this internal social social channel there where you have... You can go... It's like your...
Their internal Facebook of some sorts. So internal community, only company... Only founders can go. Not even employees of y c 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 I never get notifications about those comments. I 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 that automation. This is me as a trusted user giving my agent access to do this 1 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, like, a warning.
Like, hey. You gotta stop this or otherwise, you're gonna get banned for life. So, like, hold But me that's just me trying to solve a problem with my agent. Right? 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 gotta really rethink about how the extension of our agents... Like, I was inviting 5 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 gotta rethink.
Yeah. That's a... That's kind of the fun part of it too. Right? We get to rework a bunch of stuff, and then thankfully, with the 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 where are you at in in terms of things? Are you a 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, like, are are you all for AI in every way to help resend?
Yeah. I think it's 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 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... I'm kinda, 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 I feel like are closed loops.
So there's 1 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 post hocs. It uses the post hoc 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 the tool calls and the evals for 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 this 1 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 1 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 it's crazy how we went through the whole journey of, okay.
The the bottleneck are developers. We gotta hire more engineers. Then the bottleneck is now PRs. So we we 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 on the PR.
So we added Cubic, Pugbot, all these bots. We tried, like, all of them. And then the bottleneck became the CI. Like, the jobs were were failing or, like, taking forever to 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 the bottleneck keeps shifting. Right? And it's fascinating to follow that. You you gotta really...
There's nothing you can do. Right? You you you adopt the thing. If you ask me, do you miss that flow of coding? That moment of, like, it's you and your your ID.
Oh my gosh. I do miss that.
Yeah. What can you do? What can you do? Well, yeah. You can't fight entropy.
It's gonna happen.
Yeah.
Wild stuff. Yeah. A lot to a lot to dig into. I'm sure we can go even further. I know we got a a few more minutes here, but 1 question I'd to ask, especially whenever I feel like the person's got something up their sleeve closer to the end of the show is, like, what's on the horizon?
And maybe it could be something that no 1 knows that you can share here today, but it didn't have to be. You know, 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? Like, what's on the horizon? What's something that not many people know about that you can share?
Yeah. I... It's hard to say 1 specific thing. And maybe what I will say is connect you to that other point of, like, you gotta be challenging the way you work every single day now, unfortunately. It kinda sucks in a way because you're you're getting used to 1 way of working, and now there's a whole new wave of things you gotta adapt and you start, you know, learning and and figuring it out.
But things are moving so freaking fast that you just gotta challenge any assumption you might have. Like, I'm challenging the assumption of who I am as a programmer, who I am as a a CEO, as a founder, where do I deploy my energy. And it doesn't seem like there's... Like, in the past, I I remember it was always like, oh, now I gotta learn a new JavaScript framework. Oh, it sucks.
Like, I was just learning Amber, and now I have to learn Angular. And now I'm just learning Angular. 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 and seeing, hey. Let me try this. And then it...
It's not good. Maybe it's not good right now. Mhmm. Then... And then 6 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. What
kind of hiring you doing these things? What is it like in in 2 minutes? What is it like hiring today? Like, the peaks and the valleys, and then specifically, like, who you're trying to hire for?
1st of all, so much noise. Oh my gosh. All these fake resumes and all these weird things going on. But we we are trying to assemble, like, 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 with 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.
Mhmm. Work anywhere in the world?
Yes. Only in the system? No. All remote. We don't have an office.
We don't plan to have an office. Super small team, 4 to 5 people. Most of them, the... Have, like, engineer on the job title. Maybe 30 or 35 of them have engineer on the job title.
Mhmm. So
we... We're very engineering focused and engineering driven.
Right on. Right on. Well, as you know, I'm in a... Such a big fan of of you and the work you've done. Still to this day, use Dracula.
Still to I this really do. Like, I got... My my zed is so awesome because I have the plethora of, you know, from Van Hausing to a la carte, which I don't use too often, but every once in while, gotta go to the to the light. But but I think it's... Mobius is my...
Van Hausing, I believe, is the 1 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... Or if I recall, it's Mobius. I could be wrong.
Yes. It is Mobius. Mhmm.
Big fan of that. And, you know, so your your little d x layers just delight my world every single day, man. Like, I... Really. And I'm thankful for 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 wanna stay a 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 who don't know, and this is buried in the lead here, Zeno is the creator of the Dracula color frame... What do you call it a framework?
Color palette? Color scheme.
Color scheme. Yeah. Yeah. Is it dracula.com? Do you own?
Draculatheme.com. Been trying to get dracula.com forever, just like zenno.com, but those are the that are hard to get, man.
Yeah. Dracula might be the tough 1, man. I mean, that might be a tough 1, but but draculatheme.com. And you have... Dracula Pro still is out there.
Right? You can still purchase Dracula Pro. Right? Or is it is it not paid anymore? Yeah.
I'm a... I'm being a big fan for for all these times. Love 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 go on deeper, further, longer, etcetera, 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. Thanks so much.
You know, 1 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 gonna be at resend forward this week talking to Taylor Otwell in the building room live on stage.
If you're gonna be there, come say hello. And if you haven't heard resend launched inboxes, it is 1 of the coolest features out there. You need to create inboxes to send email, they've got you covered. I'm building something on it, and it's kinda 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 Brake Master Cylinder bringing those beats. Let's see if this show's done. We'll see you on the next 1. Win it.
Win it. It really whips them.