Full Transcript for Building what's next (Interview)

What's up friends, welcome back. This is the changelog. You know what, AI agents, they cannot drag a pricing slider. That's how Zeno Rocha found out that Claude and ChatGPT were both telling people Resend was the most expensive email service on the market, which is not true. And the fix was simple. It was a marked down version of the pricing page served through content negotiation.

And this week I'm talking to Zeno, founder and CEO of Resend, about building for agents as seriously as for humans. We discuss why following the RFC for rate limit headers matters more than inventing your own, and why agents couldn't care less about his animated icons and keyboard shortcuts. We also get into publishing your OpenAPI spec as JSON in the .wellknown folder so tools can actually find it, why agents demand granular API permissions, and the closed loop system he's building that turns downvotes on Resend's in -app agent into draft PRs.

It's a whole new world. And speaking of a whole new world, I'm going to be live on stage at Resend Forward on October 21st, this Wednesday, talking to Taylor Otwell, live on stage in the Builder Room. Learn more at Resend .com forward. All right, let's do this. Let's do this. Let's do this. Let's do this. Let's do this. Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of WorkOS.

Michael, off for agents. I feel like this is burgeoning. It's kind of happening all of a sudden. What's the state of the world for off for agents? Yeah, it feels like off for agents is one of those things that nobody knows what it means, but it's very provocative. Everybody wants to talk about it. Practically speaking, I think there's two things here.

The first is when you say off for agents, you're talking about how do I get the data into an agent that it needs to be able to do its job? And for that, we built something called WorkOS Pipes. It's actually more of an integrations product. It helps you take your agent and connect it to your customers, Google Drive and connect it to Salesforce and HubSpot and connect to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed.

That's one type of off for agents, kind of data access off. 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 third, 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 Intra agent ID, they're doing a lot of interesting work there.

There's also expansions to OpenID Connect and Skim for agents. We're building all of this into the WorkOS platform. So if you're looking for an identity stack that will support agents, again, feature proofing. WorkOS is a great place to go, but it's changing really quickly. 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 going to see, not just within consumer software, but in the enterprise, too. So it's an area of very, very rapid development. Well, it makes me think about agents versus people, and not negatively, but this world where we'll have more agents than people. You know, today, if we have seven or eight billion people on the planet, in the future, we're going to have trillions of agents going off and doing things.

And so the challenge around identity and authentication for agents is actually significantly bigger than just how people interact. In the same way, like, you know, GitHub isn't going to work super well for agentic coding because you'll have so much more code getting written. The same is true for identity and permission and logging systems when agents start doing stuff with it.

So we're building for that future today. All right, friends, the next best step is to do what I've done, which is use AuthKit. OK, that's how I authenticate my CLIs, my APIs, my applications, all that good stuff. WorkOS .com is where you go. Try it out today. A million users with AuthKit for free. You can't beat that deal. It's literally free.

Again, WorkOS .com. Try it out today. My friends, we're back with my longtime dear friend, Zenor Rocha, a man of many hats, of course. Your most recent and most successful hat, I would say, is probably being a dad and a husband. I want to discount that because I know you're a proud father and husband. But at the same time, a very successful founder and CEO of Resend.

Everyone uses Resend. That's the best, right? Yeah.

We care about email more than others. That's right. That's how I would describe it. I mean, when I first, if I'm being a little honest, when I first heard you announce Resend, I was like, why? And a couple of whys. Not like, why, oh my gosh, what are you doing? But more like, why email? Like, why is email? I mean, I know how important it is, but it's such a boring, protocol driven, kind of hard, minutia, 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 like how usage based businesses also grow over time.

And if you go after like a big audience, like how expansion revenue also helps the business. So just looking from those things from the inside. And I was a complete outsider to email. Like, man, I was, I, I'm still am learning on the job, right? Like there's so many layers to email that are incredibly wild. Uh, there's like an email conference that I went one time, like, wow, pretty crazy email conference.

Like only like the people who are running the spam filters that 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, why do we need another one of these, uh, things like we already have so many different email services, right? Like, and, uh, I just saw like, 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. I saw that with SendGrid and MayoGun. They all have been acquired by now. There's just a bunch of factors that made me feel like, you know what, I might not know anything about email, but I do know one or two things about developers and how they think.

I am a developer and I feel like I can just put myself on their shoes. To me, that's the most important thing, being able to just have a lot of empathy with users.

You can tell that you're a developer, obviously, with... I don't know how much you played a key role in your CLI and even the commands and the way it composes, but just resend, emails, send and the way that composes from the from, the to, and the subject, and the body, of course, just the way it composes 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 SendGrid and others. Stripe came about after Braintree and several others were already key major players and they dominated because they simplified to an API. And they simplified to really, I would probably describe it as core developer substrate when it comes to how you take and deliver payments.

And they took this thing that was kind of boring. Still is kind of boring, except very exciting to make some money, right? But they took this already had been done thing and global player. Well, you know, the place. When you think about sending money or accepting money or payments or anything like that, you think Stripe, right? Totally. And they were obviously a huge inspiration to us.

I remember going to archive .org and looking at their old landing pages. One of the first landing pages from Stripe had this tagline, payment for developers. And that's the tagline we use at recent, email for developers. It's 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 think about all the different industries where you don't have a Well, block tries to, right? Doesn't block tries to. I mean, Square's like the best also ran, you know, in a good way. I mean, I love a lot of folks at Square. I've got some friends at Square, 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. Okay. I was like, okay. I'm just kidding. Like, I wish I knew Jack. I've interviewed him once, but that was about it. But you know, they're an also ran in kind of a way, but they've also just like dominated in good ways too. But now they're being dominated at the hardware level, like the Clover.

And I can think of like two or three others. I can't think of this very moment, but several other players have sort of stepped in their space when they weren't really driving it. And, you know, Stripe just sort of stuck in the, we're going to provide the conduit, the API layer, and they really haven't ventured further than that. I'm not sure of any hardware on their front, but I'm sure they probably doesn't have 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 a digital layer, you know, maybe a software layer. I think the beauty of Stripe is like, they solve one problem, and they get that one problem, and they solve a different abstraction layers, right? So when I think about my own journey, as a, as a Stripe user with recent, we started, it was like January 2023, and YC batch was kicking off, right? So I was like, stressed out, oh my gosh, what am I going to do? And I have to sell this thing.

I have like growth milestones that I need to hit every single week. So I don't have time to build the whole Stripe integration. I 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, tell my friend or whoever introduced me to that person. It's like, okay, so what do you think? Do you want to try it out? And they're like, I don't know. It's like, no, you should, 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 going to scale.

We need something in the product. So then we embedded those widgets that they have. So that was great. And then once 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 like, okay, we have this problem. People might have different knowledges or even if they have the same knowledge, but at different stages of their business, here's a way to solve it.

So that, that's why I feel like they are brilliant in the way they execute. Yeah. 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 the 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 going to spend our innovation tokens, right? Every company has a, a, a limited amount of innovation tokens. And we knew that, okay, where, where do we think is the best place to put them? And to me, that was on the DX layer. So we started with thinking about like, okay, how do people actually create the email template? So then we built react email and we made it easier for folks to send emails using tailwind, typescript and react.

Right. So we build 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. Uh, then we're like, okay, how do we invest on a SDK first world, not an API first world truly believe that. So, okay. Then we invested super heavily on the node SDK, but also SDKs for .NET Rust, you know, languages that would be, you know, maybe not as used because they were either too boring or too new.

Uh, so we, we build those. And then we have the actual service, right? Okay. We're going to run this thing, how we're going to do it. And on during the early days, we chose the, the tech stack that made us move as fast as we could. Uh, so we chose, and maybe I shouldn't name names, but we chose like the, the hottest deployment platform. Uh, we chose the hottest, uh, database platform, and we weren't choosing the boring parts of tech, just the things that would allow us to ship very quickly.

And some of those vendors, they actually stayed with us for the longest time. Others, we just outgrew them. And we had many cases of that, like the queuing, system that we chose. It was great until a certain point, then we had to move to another. So at the end of the day, we do have most of our software running on AWS right now. And there are parts of that that we are like looking into either like building more of that internally, others, not as much.

We did rely on 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 one of the most exciting things for me this year. Like we're going to own that piece of infrastructure. So it's going to be pretty, pretty exciting.

But yeah, that's life at a startup. Like you choose a stack. It serves you well at a certain point, maybe then you've got to move. But there are other parts that, that, you know, we still, 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, a fire broke out, you had to step in and do something. You'd probably fire up Claude, maybe his codex. You know, whatever. Maybe your hand coding still yet. I don't know. But if you had to step in really momentarily to look at something, check a log, confirm something and do a new deployment because of something.

What is that process like for you? Yeah, we, we use CDK a lot. So in the beginning, it was all click ops, 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. Like using TypeScript. So we felt like, okay, CDK is a great way for us to deploy this in a good way.

A lot of our system was not designed as a,

like everything was synchronous. And then we, everything we had to like keep rethinking. So we started adding queues everywhere. So we use SQS for those queues. We use 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, like so heavily. It's definitely like all the other startups out there.

It's probably one of the most expensive line items. It's insane how much they charge, but it's insanely useful. So, so we have SLOs for every single part of our infrastructure.

And, but we do have like Vercel in other places too. So our dashboard or marketing website runs on Vercel. So we try to use TypeScript everywhere. And I, I was like holding that fort for the longest time. Like, you know, we're a TypeScript company, but then it comes to a point where that language is not the right fit for what you're trying to solve.

So we have one piece of the infrastructure was, which is the actual pipe when we're sending the emails. And we rewrote that in Go, uh, recently like three or four months ago. Um, so those parts are way more scalable right now. And, and, but it's all very modular now. And, um, can you share some details about that, uh, that Go rewrite? Like what was involved? Like, what does the pipe do? Why, why did Go make more sense? Was it probably 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 things about that really. Yeah. So there are two different ways of sending email at Resend. There's one where you call the API or sending one email, you just go, right? So we queue those emails. So even if the database is down, we can retry them later, all that kind of stuff. But those ones are fairly straightforward, right? You can also schedule an email.

So there's that aspect, uh, 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. Um, how do I do that? So we found that if you just send 10 ,000 emails all at once, Gmail will look at that and be like, huh, this is weird.

Like why you're sending all of that volume all at once. Right. Uh, so what every single email platform out there in recent does that too, is that whenever you're sending a big batch of emails, you have to separate and break down those batches into mini batches. You have to space them out as well. And depending on the size of the audience.

So if you have, uh, 300 ,000 listeners and, or you, you have like 3 million, uh, you know, we need to like space those out so that you're not going to be trottled by Gmail, which is what happened. Uh, Gmail looks at those emails that are coming in and they might say, you know what, this is way too much. Like I'm not going to place them on the inbox right away.

Let me see the first ones. And depending on that, I might move them to the right place. Um, so that part was really tricky because you have one customer sending 5 million emails, but then you have, I don't know, dozens or hundreds of customers sending 5 million, 300 ,000, like all at once. And we were struggling with concurrency with node for all those batches.

Um, and so it was tricky to handle that. And goes, is much faster with concurrency. Um, that sense. Yeah. I'd imagine, um,

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, partners, et cetera. How do you think of, how do you, how do you solve that problem? It's a smart part of the platform. Uh, so this is something we do behind the scenes to protect you as a sender.

Um, some people that are like, Oh, it sucks that I have to wait four hours for all my emails to be sent. Three million. I wish they would all go at the same time. Um, of course you, you do wish that to happen, but at the same time, if you do that, um, you might have all of your emails landing on spam. Uh, so depends on the shape of how many emails you're sending in the past that also, um, 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 send to those inbox providers, they would just either throttle your sending, which is what you know, does very often or send straight to the spam folder. When you fit this, uh, this go application and 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 blue green it? How did you approach the swap and have you swapped? Did you swap it over yet? Yeah, we did.

We had multiple false starts. We would try to go with that and then, oh my gosh, something broke down the line. The shape of the email body and all the headers, because we were building this new system, maybe someone would send an email with some foreign characters that we didn't anticipate. Okay, now we have to go back, fix that issue. So it was a gradual rollout.

It took multiple weeks before we could actually have every single user using it, but it was transparent. Like no one knew this was happening. We haven't even talked about it publicly. This is the first time that I'm actually saying, oh, we use Go at recent, you know? Nice! I'm a fan of Go. You know, whenever I think about my thought matrix when it comes to that language, the first thing I want to choose is TypeScript, because it's so versatile.

It's obviously the language of this modern era when it comes to anything agentic, which is pretty much anything these days. You sort of have to embrace TypeScript. And the agent, the model doesn't really need the types, but what it does enjoy, I suppose, maybe it doesn't enjoy it, is the intentional determinism when it comes to Zod and schemas and types and things like that.

So like all that the TypeScript does, the agent doesn't need to remember the types, but it does need that system to remain sort of like guard railed. So it doesn't have to do these wrong things or right things. And so I tried to choose TypeScript first, but I find that more often than not, the better shape for almost everything I want to use is a simple binary, is literally a binary, not a bunch of files that I have to then deploy and maybe compile if I'm using Bunt or something like that, or make it executable if it's, you know, note or something like that.

So like just different things like that. You know, I find that Go really is the better fit in almost every case. I really just wish that Go had a better web story. Like once you get past the system, the API, you know, all those things as long running services, you kind of, I mean, there is web stuff there, but nowhere near obviously the world of JavaScript, which is kind of a bummer.

I almost wish that TypeScript and Go would just somehow merge, but maybe not. I only want one choice, but it's a beautiful world we're living now where we can choose more than one language and we don't have to be TypeScript for life as you may have been in the past. Totally. And like, I wish there was a Next .js for Go, right? Like, or even like an Express for Go.

You obviously have a big ecosystem there, but there's something lacking when it comes to the web, like you mentioned. But yeah, it's just beautiful. Like the idea of like, okay, you have a system, you have all the tests and that's what matters. And you can just swap languages based on those tests. Like how crazy is that, right? Like if we decide in a year from now that, you know what, let's move from Go to Rust.

Obviously there's some work to be done, but there's so much you can do with that test suite. It's crazy. Can you share how difficult or some of the things you did to make Go fit into your TypeScript world? I imagine you're sharing like schemas via Zod or something like that. So they're able to use the same types, maybe even borrow the same types.

Did you have to build anything, any middleware in between the languages to make them play better together?

It was definitely a struggle because we already had a monorepo, but there was still some repos that were like scattered around.

And for this to work, we had to bring them over to the monorepo in a more intentional way and try to reuse the types as much as possible.

But we didn't build like a layer in between them or something like that. But there was definitely like some work, even like when you're setting up CI, okay, now we have a different way of building this whole monorepo. How do you do that?

We use Turbo Repo a lot, but okay, how do we fit that with Go? So, and the software development lifecycle, right? Like now you don't necessarily have preview URLs as you used to in certain parts. Thankfully for this part of the system, we didn't need that. But you start getting to those things like, oh, people simply don't have Go installed on their machine.

So now, okay, let's teach them how to do that. So there's little things like that. And we use Docker, like the traditional stack that you would imagine. But the moment you go multi -language, there are– the linter you use, now you have to worry about that. Oh, it needs to support this other language as well. So you start to look at things like, oh, how we can use a different linter or same linter.

So a little bit tricky. Test suites, another one too. Yeah. Well, 3 million users is a big deal. Last month is a big announcement. I think it was like six months before that, you were at a million. So obviously you're growing fast. I think we're in a unique era for a lot of services. I think you're in the perfect scenario where you could be at, which is kind of where I started with the conversation around being like, why resend? Not necessarily like questioning your direction, but like, really, email? But yeah, really, email.

What a moment where now we can automate so much with it. And so I thought it was kind of funny in a way that here in 2026 you would announce an official CLI as if that wouldn't have been like step one. You know, like, honestly, I couldn't deliver, build, or operate a service unless it has a CLI. So I'm sure you have like an ops CLI in some cases for your systems, but a user -facing CLI is finally announced.

So 3 million users, this new agentic era, official CLI. What's the nugget in there we can talk about? Man, I'm sure you felt that way too, but after January, it feels like the whole world changed, right? We're coming off the holidays. Cloud Code is here. Opus is here. And we felt like how that changed the market. Like it just changed in a big way.

It changed the way we use different SaaS tools. I found myself like building my own little apps. But more than that, like the entire infrastructure as a service category, I would say, benefited from what happened, right? So recent is growing a ton, but we're not the only ones. Like the companies who are being suggested by Claude, suggested by OpenAI, they are riding that wave same way as we are.

And it turns out like once you have those integration points, like the CLI, things that you would imagine, oh, they're so silly, right? Man, the things you can do once you have a CLI, like that was like impossible if you didn't. Or now with MCP, like it's just insane. Like I see people and I see myself using Claude Code, Claude Code work as my operation system.

And I do work from that and having those integrations in place is super important. And then the tools that don't give me that, I'm like, I just can't use them. I'm like, I need an MCP server, I need a CLI, like there's no negotiation. Like I would just move to something else. Yeah. Yeah, I feel like, which is kind of the comical thing here is here we're in 2026, officially having a resend CLI.

What took you so long? Yeah. Were you just too busy? But like, I know in three 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? Yeah, that's a great point. That's a great point. We built CLIs over time internally, like during hackathons and stuff like that.

But I've always felt like, man, who's going to want to send an email from the terminal? Like we are trying to help businesses to send, you know, transactional emails, reset password, welcome emails, like whatever you need to send, right? Usage emails. But would someone go and like spin up their terminal and try to send an email from there? My feeling was like, oh, maybe not.

But turns out you need all these other tools around it, right? Like you are configuring Figuring a domain, you are looking at your logs, those things are extremely valuable to have on your terminal. And then when this whole craziness happened, we just had to build one. For myself, I was spinning up all these OpenClaw instances internally for the team and for my own use.

And there was no way I would have to give my OpenAPI spec, it would generate a super poorly written CLI based on that. And I just hated that. So we're like, no, let's actually build one. We chose TypeScript for that one because we wanted to make it open source. We debated using Go, but we just said, you know what, let's just go with what's better for OpenSource contribution rather than just deployment or build or performance necessarily.

And yeah, it took us a long time and it took us a long time to ship the MCP too. With MCP, what was hard was we built the MCP server, we made it out there, and then all the MCP clients now require like an all -off authentication method by default. So we had to go back and say, okay, now let's revisit our whole authentication layer and how we save every single request, how we do everything to support not just a single way of authenticating requests for an API key, which is what we had.

Put your bearer token on your headers, you're good to go. So we had to rethink the whole thing, deploy the whole thing, think about like auto trailing and observability for MCP servers, which is a new thing that's emerging too. And then now finally we ship like a hosted remote server. So yeah, it's crazy how those things take longer than you want, those interfaces.

So I see that as an interface layer. And at the same time, you have users asking for the product layer. They want features. Of course, they need different interfaces, but they actually want different ways to interact with email. So for us, we started with marketing. Then we started with transactional. Then we added marketing. Then people asked for a way to receive email.

So we added that. And then they asked for automation. So we added that. So we have all these different things you'll have to build to actually solve user issues as well as improve your interfaces. It's crazy. It's just so much to build. What does it take for you all to receive an email? Of this list, the things that really stand out to me is receiving an email, broadcasts, and automations.

But that's just my take. Yeah, receiving is tricky because first, just the setup can be tricky. You add an MX record. But then if folks use Google Workspace, now there's a competition between the priority of the MX record. So you've got to deal with that. You've got to teach users how to deal with that once there's a conflict. So that was one challenge.

And we think a lot about friction. And that can be an action that if someone is just distracted and they try to set up in a way, they might break their whole organization. And they don't even know, oh, my emails are not, you know, I'm not getting any. It's silent, too. It's like there's no observability for you. 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 wild card usernames, like support at whatever, security at whatever, sales at whatever.

So you've got to deal 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, especially the inbound. How did you approach? How do you approach that specific problem set? Do you like how old is that product? And when you thought about it, did you sit in a room for a week and just dream about where it can go? And what that first, like, even for the first thing the user needs, like, what do they need? Do they set up an email inbox? Do you automate it for them? You just tell them records and they're going into

Cloudflare dashboard or wherever, you know, they're doing their DNS, DNS simple or, you know, wherever they're doing it. Like, how do you even approach that kind of problem? Yeah, it was a wild journey because the first thing is like, man, I got to feel the pain myself. If I don't feel the pain myself, then there's no way I'll be able to build a great product.

So we were like, okay, looking for use cases internally that we will be able to receive emails, triage them, automate, like, okay, based on a support message. Let's not necessarily reply, but draft a reply for a support team, whatever it might be, the use case, right? So we like, it was a journey to get to that. And then there was a journey to like, first of all, users were crazy about this.

This was our number one most requested feature for over a year. And we were looking at that. It was always at the top. Like every support ticket we have, we use plain for support. There's a way to link to a linear ticket. So we link every single feature request. And this one, the frequency was just so freaking high. So we're like, okay, it's an obvious problem.

People want us to solve that problem. So let's go try to solve that problem, right? Similar to SMS, what's happening to SMS right now with us. But the problem is I don't feel like I'm feeling the pain as a user. So that's why I've been 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. So 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 like going with like picking like three or four engineers and just like locking ourselves in a room for a week.

So then I remember I traveled to Sao Paulo where we had a few engineers that were joining the team and then a few that were there already. So I think we're in five or something. And then we just kept like building that V0 of inbound.

And the reason why I love doing that is because you have to make so many tradeoffs as you're getting started and you're in the room. So the team is like, oh, I have this blocker. Great. Let's just do this. Let's just do that. And you're feeling the DX as you're building as well. And then you uncover all the now you have known unknowns. Great.

Now we can go back home and actually build the thing and actually make the thing work.

But I love going. I got to feel the pain. If I don't feel the pain, it's just I know that the end product won't be as good. And not because I'm special. It's just because I won't have the empathy. I need to feel like, oh, this sucks. This sucks so bad. And I go through like Dracula. And that's why I'm like, no, I go to my Dracula domain, which I do use a Google workspace.

And I'm like, now I have to configure the DNS settings. Okay, but oh, the conflict. Oh, what do I do now? I'm lost. How do I overcome this? So that's why I love having side projects until now because I can always use them to feel that empathy. Is this mainly giving, I don't want to just say like an agent. We've said an application in the past, but I feel like now our application layer kind of has an agent to some degree available or nearby.

Is inbound about handing an email address specifically to an agent or an application layer? How is an inbound user? What was that pain you mentioned? Yeah, there are many use cases with inbound. So there's one company that we help them. They do trip management. It's called TripSee. Amazing app, by the way. You should definitely check it out.

It's beautiful. One of the most beautiful iOS apps I've used. And what happens with them is like, oh, I just booked a flight or just booked a hotel. I need to forward that email as a user to this special address. And then that address will then receive that email and then will parse the whole email. It will use whatever it wants to use, either deterministic or it will use AI to extract the information, then save the information.

Right. This is one use case and it's a use case that I like a lot. You are forwarding a PDF, you're forwarding whatever you want, like or a CRM where you are adding a BCC and that gets the content of the email and saves that email. And the reason why I like that use case is because it's more B2B.

But then you have the B2C type of use case where I'm setting up my open claw. I needed to have an inbox and I just I need my agent to have an inbox. That's it. So then, OK, 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 wild card solution, which is what recent is right now. You set up inbound every single domain doesn't matter the address. It goes there. Now what we're actually building and it's it's looking really, really cool. We haven't shipped that yet, but it's a full inbox.

So you want to have a box 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 one 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 asking us at the minute, like, you know, if we five or 10 X our throughput this year or a thousand exit, what breaks and when? And, you know, my answer is kind of same as it's been for the past 20 years, which is that the bottleneck is still trying to integrate those code changes in and then deploy them and check they work and then keep them working as you keep throwing more and more code at it.

I think a lot of the fundamentals are the same, but we're just a thousand X in the speed of it. And, you know, that changes nearly every variable. Yeah, for sure. OK, so we're 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.

Like we've been disproportionately successful in that small niche, the kind of Shopify class, Uber class, you know, open AI class of folks that have this key problem around iterating really, really fast. And, you know, the thing about all 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 got to spend some time assembling those building blocks, those Lego blocks to get the thing that you want. But the end result is far and away more performant and scalable and the experience is better than what you get from something that's off the shelf.

So I think we've started from a position of really well engineered Lego blocks and then are kind of working backwards towards kind of creating the thing that scales down to a startup that starts with one person and 10 agents next week. Well, friends, go to buildkite .com. That's buildkite, K -I -T -E dot com. You deserve better CI. Engineer for the frontier we are all facing, trusted by the teams setting the pace.

Again, buildkite .com. Once again, buildkite .com.

When you were designing for 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, one of the ways you define your societal identity, like if the police for some reason came to your house, nothing bad.

But they just came and they said, I need to see your identification. We're just doing, you know, for, you know, for all the reasons why it's fine. It's fine. They ask you this. What do you hand them? You don't hand that. Maybe you hand them your hand if they're going to take a fingerprint. That's weird. So you can identify that way. But the most common way we do it today in society is with a driver's license identification.

That's an API key, right? It's got a driver's license number on there. You 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 is my driver's license. And so I'm curious how close you came to thinking about identity when it came to giving an agent inbox. Yeah, man, I actually thought a lot about that.

And we obviously had the news this morning about better off being acquired by Vercel. That Twilio also acquired an identity company.

So for a moment, I thought about that idea because I take a lot of inspiration in terms of what the connections that other products were able to do. So to me, PostHog is brilliant because they saw something that no one saw. Like I was using Mixpanel and those tools forever, right? Like Amplitude for product analytics. Never I thought about putting feature flags and product analytics in the same product.

But they are adjacent, right? Once you have those events, now you've got to figure out what to do with them. 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 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 one of those things. Preset passwords, magic links, you know, there's a lot there.

And I haven't cracked the code for recent yet. I haven't made that brilliant connection that, oh my gosh, now it makes so much sense. It could be background jobs because no one sends email or most people don't send email right away. They put those emails in a queue or in a background job and then they, the outside of the critical path, right?

So there are adjacent things that we could get into, but so far it's been, man, we just got to focus. Like there's just so much to do. Those 3 million users are asking for so many things here. Yeah. Let's just stay in our lane, at least for now. We are obviously expanding the footprint of the product, but we haven't taken that like extra step to go into a completely different vertical.

Very cool. So those 3 million users are probably pretty, to some degree, vocal. I'm sure there's at least one third, you know, maybe one fourth that are more vocal than the other 75%. Maybe not. I don't know. What are some of the things that they're telling you that makes you know, like give you assurance or some version of assurance that we're going the right direction? Because when you have a swath of, a large swath of users telling you which direction to go, you kind of, you kind of should listen, right? And so are they saying, I want identity with my email? Like what are some of the things that they're really pushing you towards when it comes to product?

And so it's hard not to look at them and be like, you know what? They, 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 recent email could be one channel, but I'm just trying to get to users and comms channel really, right? Like a comms gateway.

They want, they want one place to go, one API to call, one dashboard, look up one log to reason, you know, et cetera. Exactly. And I feel like that's the future for recent. I think at some point we'll get there, but time and time again, every time we like 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 roadmap for the next 10 years easily. Like even if we just stop paying attention to everything, there's just so much to build. Wow.

I'd imagine in this era too, you have a lot of pressure to deliver something very, very soon. What are some of those things that you have to deliver very, very soon? Like what kind of customer types are they? They tend to be humans, community agents. So technically it's an agent. You know, what are, 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. Um, and you just, uh, uh, uh, 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. Um, 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're 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 first out time, I knew very quickly, like, okay, this is a different type of business. Yeah. Now you're, you're utility now. Yes. People call you, they expect you to answer quickly. Every time. Every time. Yeah. Like go there and flip the light switch on. If it doesn't flip on, you're like, who didn't pay the light bill? What's going on? Like you expect it to be there.

Where is my resend? Totally. And for some apps, it's like, oh, it's okay. I'm just sending a marketing email. It's fine. For others, like, no, my, my users are not able to log in. Like you guys are like letting me down. Like there's no way. So then we have to jump super quickly. And we have a big success team. My big, I'm talking five people.

But 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 pretty small team still. Yeah.

I don't want to ask you this question with a negative, but I'm going to do it just to get a reaction and just to dive in a little further. But like, is 3 million users a lot? Is that a lot? I know it's a lot when you go from zero, when you have zero strangers, zero strangers using your software, you know, I get that that's a lot of users, but like, is that really a lot in the grand scheme of the space you fit in? Given even the change, you know, with SendGrid and others, like just changing around the scenes, like you seem to be the most, you know, Stripe, API, amazing DX, I would say maybe even now borderlining, amazing AX, Asian experience.

Is 3 million a lot? Is that a lot? Yeah, that's a good provocation.

I saw recently that Superbase had crossed like 10 million users. That got me thinking, like, oh, is this the TAM for developers? Is that how big it can be?

I forgot now, but on the Twilio website, it was also around that. So I'm like, okay, how far can we even go?

So to me, what's interesting is like, the definition of a developer is completely different, right? So if we're building for developers, what really is a developer these days?

Crazy story, man. I was at Vercel Ship last week in New York City. And, you know, I was at the booth talking to people and it was great because Vercel Ship is different from Next .js Conf you can tell the vibes in the audience. There's a lot of VPs and CTOs and CMOs all that kind of stuff.

And during the afternoon I had just finished lunch and a guy that was working at the catering company, he was like with some dishes, he was walking around, he stops me and he's like, oh, are you from Resend? Oh, I use Resend. I was like, no way, tell me more. I even took a photo with him. He's like, oh yeah, like I'm trying to learn how to program on the side and I use Lovable and I use Resend.

I don't use Resend yet. It's too complicated, but I use these tools and it's great. I was like, man, that was so special to hear. And I'm just reminded, this was like, I don't know, six days ago. I'm reminded about, you know, the people who are serving. We do have email for developers as a tagline. We have so many designers, so many, I don't know, product managers, marketers using Resend and builders.

I feel that that's what ultimately these people are, right? So how many builders are out there? It's way more than 3 million, you know, 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 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 like the time to a ha 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, you know, they reward you.

So, yeah, I don't think 3 million is a lot.

I feel like there's way more to go. Way more to go. Yeah. You know, you mentioned that user. I got a friend of mine. I'm going to mention his website. I was, that's why I was looking at my phone right now. If you saw me looking away for a moment, I was trying to think because a good friend of mine, Hamilton Heald, he and his wife started this, this beef tallow chapstick brand called Meadow and Hyde.

And it's a meadow and Hyde dot CEO, for example. And when he told me he built his website with bolt, I think it's bolt dot new.

And he said that he sends his emails with recent. I was like, what? Same thing, you know, like with you after lunch and this fellow, 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 a developer in the past. Meanwhile, he's built. If you go to meadow and Hyde dot CEO, 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 recent, you have to use your RE underscore API key. Right. You're going to get this API key and it's like your driver's license in a way or not. In this case, maybe it's your ability to access something. I don't know. It's a key. It's it's so interesting in this world, like it's to explain what an API key is.

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 digital version of that same concept. And it's got the certain grooves and, you know, cryptography. That's basically physical 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 it's been pretty foreign for the user to ever ask you for your API credentials or to create a no off to 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 want to have someone on your team.

And maybe this person's newer that they are your tech seat person. And in that tech seat, they're procuring your API keys. Maybe they're even weaving together services and they're not in the command line. They're inside a lovable. They're inside a bolt and they're inside a cursor, for example. And they're weaving together these keys and stuff like that in these services in this whole new world.

And it's it's kind of wild and exciting at the same time, because my buddy building a service and his website, I say, what? And he showed up to me. I was like, this is good. Like, this is good stuff, man. Like, it's not vibe at all. But but it was vibe. It was a version of vibe. But here he is shipping products to people physically and using recent to send the emails like that's wild.

So he's one of three one of three million for you. Yeah, it's insane because you see.

Like how much empowering technology can be like on the grand scheme of things, right? Like the things you can build, the fact that with plain language, you can get stuff done. It's so also so beautiful.

And it's also super challenging, too, because if you are one API key away from doing whatever you want to do, you can do a lot of bad things, too, if you don't have the right intentions. Right. So we have a big challenge in. OK, we want to make it as easy as possible. Great. How do we deal with those bad actors? Because there are weird people out there trying to send some weird emails and we block a lot of them and they keep coming back.

Now, 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, 100 domains. Thousands of domains with different registrars, different DNS services.

And they all try to take advantage. And if you have a free tier, good luck. You know, that's an added problem to this thing. Yeah. You want to make it easy. Yeah. But it's so tricky. Like, for example, account provisioning. Let's say you just want to do that programmatically.

You want to hit an API to even create an account to be able to create an API key. Those are the things I started to see when I was pinning up my own agent. I'm like, go to recent, try to create an account. And I had a bot detection at first on the signup page. I'm like, no, I'm removing this. This is not going to be here anymore. So I just rip it off.

I rip it off. This was like a Saturday afternoon. I rip it off and I'm like, no, we're going to have bot detection on the login, but not on the signup. And then you try to make things easier. But yeah, it's hard. But then you'll hear those stories and oh my gosh, it's just beautiful. The power of these models these days and people with great ideas can just make them happen.

You bring up a good subject, which is the free tier. And I know that you have a free tier. So you got a zero per month, 3 ,000 emails per month. You got 10 ,000 automation runs. So you're giving quite a bit there. And this is all in the name of attracting customers, right? They call these trials. Your trials convert.

How difficult is it in today's world, given the upswell of interest in Resend? Is it to honor that gift of free tier? Yeah, it's hard. I think we 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 actually You actually need a lot of staff to cover for this too because abusers don't stop.

So it's hard and we were doing like an exercise in like, okay, think of like crazy ideas, go insane, moonshots, how we can make this one part of the company easier. And for trust and safety, like one of the moonshots was like, oh, let's kill the free tier. You know, in one second, we're going to like remove all those problems away. You obviously create many other problems and it just doesn't really speak to what I'm trying to do.

You know, starting as a software engineer in Brazil, I didn't have any money for the services that I was using. And thankfully, GitHub had a free account. So I was able to get started with that. And then, you know, as I was building, there were other like the free tier is something that enables, you know, a new generation of people to get into tech in the first place.

So to me, like there's no way we're going to get rid of the free tier. And of course, you're not doing that too, just because you are like the most generous person in the world. Those people actually convert. In fact, just today, this morning, we crossed 100 ,000 paying customers. So three million users total, 100 ,000 paying customers. And it's just like if you have the right incentives, the right levers at the right places, we had to add those to make sure people like.

So it's 3000 emails every single month for free. But you do have a daily cap. And those things help us move users from one tier to the other. But they are still generous enough, right? Like it's 100 emails per day. If you're sending over 100 emails per day, OK, maybe you have something going on. So then, OK, now you can pay 20 bucks. It's not the craziest thing, but still is for many people.

Then I have to shut down that service or not. I think for me, it's a dual thing. It's both like a do good type of thing. And we even articulated that if you go to our philosophy page on the recent website, that's the first thing that it will talk about, like make it for everyone. So we talk about how there are developers not just in New York or San Francisco or London.

Like, no, they live everywhere. They have different access to the Internet and 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, V0, man, those guys, they were driving so many signups to recent. But our revenue was just like growing the same way. January 2026, completely different because Claude OpenAI, they are recommending recent. But those are actually paying customers that had the problem and we happen to be at the right place at the right time. Right.

So it's a different type of user, but you shouldn't neglect them. Yeah. Even if they're not paying you right now. That's a good point. I mean, really, it is. I mean, you can scrutinize almost like long term thinking versus short term thinking. Right. Your short term thinking is like all features bad. Long term thinking is not actually free.

It's really good. You just got to get past the pain of it. You got to like look at it as a non burden and look at it as a praise and 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, a 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 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 one plan to the other. People are always complaining about those levers. Right. Right. So in the free plan, it's like one domain and people are like, oh, I can't use recent because it's only one domain. And then they try to create multiple free accounts to bypass that.

So there are things that you do to try to accommodate for one thing and then you lose the other part. So I think about pricing a lot and positioning too. Right. So we could have like a cheaper first plan. That's like people ask that all the time. Oh, I wish like twenty dollars is too much for me. I'm in Africa and it's a lot of money. Right.

OK, so let's make it 15. Let's make it 10. Let's make five dollars. But then how is your product perceived the moment you you you change that to. Right. So we were trying to position recent as this premium product, a product that you go and you feel the love, you feel the care.

So, OK, 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 for contact. And in this age where you launch an app and I have a million users out of nowhere, like pricing for contact doesn't make sense. So we are revisiting that, too. So some decisions we made because we're like, oh, let's just follow the market.

It's just easier. Like we're not going to innovate in pricing. Let's just mirror what our competitors do. I feel like that's a great idea at first. But now you realize like, oh, no, what a dumb decision. Right. Like pricing is part of the product. You cannot get away. Look at any ask any SaaS owner. What's their most access page after the landing page.

And they will tell it's slash pricing like that's the page.

So it's part of the product. And you cannot ignore that.

Well, on the on the copy front of your pricing page, it's stellar. This is probably the most clear page I've ever seen in my whole life. There's no fluff. It is exactly what you want on a pricing page. I'm not sure what what role you personally played in this, but the slider of helping you choose which tier like people want to know not just what do you offer? And how can I pay you to get what you offer, which is 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 going to 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 slider that really shows you like, oh, once you get past a certain number here, clearly you're in the scale custom enterprise realm. And so you almost sell them with facts. You know, you're not selling with like probables.

This could probably happen or these, you know, this is exactly what you're going to do. Like if you're going to send in the 500 ,000 range, you're probably going to be in the scale territory. And to me, that's really cool, like how you've designed this page. But how do you see this page changing? I know that I can't recall what it was. I think I saw you do this, where you just added a .md to the end of things.

I think, did you start this movement? I said, no, I think this is you, right? So how much traffic is this page getting that is non -human now that's still influential? And how do you influence the non -humans? 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 good, but it's good for humans.

It's not right. It's terrible for agents. Yeah, it says not. Well, I mean, maybe operably, like, do you give them some version of, maybe this is an API and it's interactive. And, you know, I don't know, like pricing is an API page versus that. And you're like, how do you get your pricing? Well, tell me what your payload might be like. How many emails do you want? How many will you send? Is it transactional only? How many per day? You know, and all that is maybe an API call and the response is JSON.

It's like, here you go. Or maybe it's market. Maybe it's actually markdown. I don't know. But anyways. No, totally. And we, the way I found out about that was again, a Saturday afternoon, I'm just tinkering with stuff. And then I asked like, oh, I was creating maybe a competitor analysis on cloud. And open AI. I wanted to see what they would recommend.

And then they told me like, oh, recent is the most expensive service. And I was like, no, I know for a fact that this is not true. Yeah. And I was like, so surprising. 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 able to do.

And I'm like, okay, we need a markdown version. So I made the markdown. I changed the alternate header. So if you were to request that with a different header, then it returns that. And then I just started to like seeing for real life. And then I just made the requests and then started to get the math right. Like all. So what I did was, okay, I'm sending three or 2 .3 million emails a month.

How much would I pay with recent? And then it would get the number wrong. And then I was like pushing changes. I was like, oh, let me update the copy. Let me update this. And then when I added the markdown version with an alternate header for content negotiation, then it finally worked. So I was like, oh, okay, nice. So in the end, it's like you, you, if you're not playing with your own products, or if you're not like pushing 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.

It's like no one 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 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 then 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 one. It's always on the first day of the month. And I try to make it like very, very early in the day. And I do include all the lovers and all the haters of recent. So if you're a lover, if you're a hater, and you tweet about it, I will see it and I will include on the investor update.

And I just keep inventing those excuses. Like, right after this call, I do need to send an email for Dracula. We already have the draft done. And I'll just go ahead and send it. So I'm always like, coming up with whatever reason I can to, yeah, to use the product. Mm -hmm.

That's cool, man. I feel like that's definitely the way you uncover the real potential too, right? Not only uncovering all of your blemishes that you need to fix, and you can only discover them by using it. And what a user will do is they will get frustrated and go away. Some will complain. Lots will complain. But by and large, you know, no one's just knocking down your door telling you all the little things.

I mean, there's support for sure. But unless you're the builder and the building team that's using it, unless you're using it on the daily, you're not really going to discover the warts or the real potential. You know, you start to really like obsess and immerse. It's almost like method acting. You know, that's something about like in the moment.

It's like kind of like method developing. You know, to get some of the best characters we've seen on screen in Hollywood, some of these actors have had to go through life -altering scenarios where they will go so deep. Like Jim Carrey went so deep on 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 pretty interesting song up there that's popular now called Go from the Chemical Brothers.

And it's pretty popular because of the movie Apex on Netflix with Charlize Theron and Egerton something or other. I forget what his full name is. I'm sorry, dude. But he played this character so well. Anyways, I'm sort of on a tangent here, but music was a really big deal there.

Where am I freaking going with this? Where I want to go with this is actually back to Asian experience. That's why I was trying to go with this was was to not get too lost and we're getting close to our time here. But yeah, I feel like this space we're in right now. The way I think about things, I'm curious how you feel. And I feel like, yes, as of January, the the table shifted, the whole world moved and it's a new trajectory for almost literally everyone.

Is now this idea that you're not really building the feature for the human kind of you are. You're doing it for human intent and human enjoyment. But the the thing the automation layer the intelligence layer doing the work is the agent and I've always known you as someone over all these years really is to be someone who really focuses on developer experience and now we have agents and so we have agent experience ax and anytime I'm talking to my agents I'm always like you know this has to suit DX.

Slash ax and it's always including those sort of two labels there to justify my actions of 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 they have a whole entire blog post on this and and all the good stuff. What is it that you think about when it comes to agent experience and building for agents these days? Oh man, it's so hard because there are all these little things that I I obsessed to get DX right so for example, you go to the dashboard, you have these animated icons right so it gives you a sense of like, oh, okay, these people actually care.

It's a little bit different when you then 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 a reason 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 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, if you have an open API spec that's important, all that. But then there's a lot about discoverability too.

So what I found was, okay, we had an open API spec and then I was asking my agent like, oh, go fetch the recent open API spec. And then it didn't know where to go. So I'm like, oh, no, like I actually need to. So then I went on this tangent of like, how do I make sure that every time we have an open API 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 one really knows what they're doing. Or if someone claims that they know how to solve for that, I would challenge that assumption. But you learn as you're going, right? Like you try to get stuff done with your product.

Like we use this tool called 2027 .dev where you give it an eval and then 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 different platforms. And then we try to see where do agents get stuck.

Oh, do they get stuck here or there? How we can make sure they don't get stuck at these points.

I remember adding a lot of like copy page content as markdown so people can just base on their agent of choice. Like we do have an agent that we ship in product. But maybe many people, they just want to use theirs, right? They already have all the context there. So we try to make it easier that way. Like, oh, copy the logs as a JSON. I'm revisiting the error messages now because the error messages are crucial.

Like if they're super generic, the agent gets stuck. So they know, okay, there's an error. Great. You want the agent to see the error and then try something else. So like you have to think about what will be the next steps once the user gets this error. Like rate limits. Oh, my gosh. We had to revisit rate limits because agents, they do way more requests than a normal human would do, right?

So it's insane. Like there's so many layers to this.

Well, friends, this episode is brought to you by our friends at Coder .com. Secure environments where developers and agents work in parallel. And I'm joined by Nicky Pike, field CTO for Coder. Nicky, what is a field CTO? So I get that question a lot. And it's, you know, half the people understand it. Half the people don't. So a field CTO, I describe it very simply as we're DevRel for the C -suite.

So we provide a bridge between the customer voice, between the C -suite and the managers and the leadership teams of our customers back into our product. And then we go through and we help enable our teams to have the same message to make sure that the message is correct and that we're building on something that people actually want, not just something that we think they want.

Okay. So we're taking the laptop away from the developer. Not really, though. We're putting them in a cloud development environment, a secure environment where they can work with their agents in parallel. These are blessed environments. What's wrong with the laptop? The laptop is the is the trap here. And not only because the fact that it could be stolen, you could lose it.

It breaks and you're out of work while you're waiting for a new one. But there's also just the consistency that you got there. We all know developers. Developers are going to be looking for some of the latest and greatest. And if you're not really controlling how they get out there, that's where you get this. It works on my machine. It doesn't work 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 four to five weeks for a new employee to really get their local laptops set up and ready to start doing their first time of code.

And, you know, the time to first commit is a metric that almost everybody knows. And the reason they can't do that is because there's a lot of tribal knowledge out there. They got to go talk to other developers. What are we using? Where do we get our dependencies? Are we getting them from public? Are we getting them from private repositories? But there's also the security and the supply chain aspect of this.

When you have local machines out there, look at like the Shai Halud, you know, that virus that went out not long ago. This was a compromise of the NPM public repositories. They went and downloaded things. NPM did what it did. Next thing you know, you're compromised. But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo.

Those packages are expected to have been thoroughly vetted. We know that they're clean. Now, does this stop everything like Shai Halud? 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 five minutes. You don't have to wait all that time.

Well, friends, the first step is to go to Coder .com. Install Coder. Self -hosted environments for your teams to enjoy, to standardize around. And it's open source, so you can try it out today. Once again, Coder .com.

That's a good point is this agent experience is not just crafting a good experience, but when you hit the hurdles and the bumps, course correction. Because that's when the turn will bound, right? You'll come, the agent will get stuck and come back to the builder, right? And that their literal 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 mutation change or whatever on their own. They must get an operator or 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 five minutes and your limit comes back or whatever the number is.

Then the agent's like, well, while that five minutes is going, one, I'll set a loop because 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 five minutes.

They're like, right, resend's available again because the API limit's gone. They never had to go back to the user that's building with them to change that. They could have just– 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 kind of do with the CLI.

They just sort of like brute force a CLI or an MCP server and figure out what they can or they can't do. And I don't know if they really mean to be because they're not like cognitive, not yet at least, AGI, but they're not trying to hurt your servers or abuse your servers. They're just trying to learn how they can use it. And so if along the way you have better milestones, waypoints, and just error responses, it's going to be a lot easier for that agent to get feedback from the system it's trying to learn while it's using it.

So true. And, man, we've learned that lesson the hard way in the sense that the primitives are the most important thing that matters right now, like getting the primitives right. So what does that mean to you? Write that down. For example, the rate limits, you can just have a proprietary header to just like respond with the– like where you are in terms of your rate limit.

Oh, you've used six of your 10 requests so far. Great. So this is one thing. Like you go to many of these really like good services. They might use like a language that they have for themselves that they invented, right? Well, there's actually an RFC for rate limiting with three different headers, one for the count, one for the unit of time, and then one for when you should try again.

You should follow that RFC because if you follow 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 right headers, the right ATP verbs. More than ever, those things are crucial. And if you're trying to do something that's like a proprietary thing because you believe that you have a better opinion than others, like the agent will know what to do.

So yeah, you need those. Like for example, we always had like a YAML OpenAPI spec. And then I would use all these agent experience core services that are out there. There's so many. And because I'm a nerd about this, I keep like putting recent to see how recent will score. And then like two of them told me like, oh, you don't have an OpenAPI spec.

And then I saw like, why? Like we do. Oh, they're searching for the .json version of the OpenAPI spec, not the .yaml. So now I have to build a thing that converts from YAML to JSON, deploy to the right place. So there is discoverability for that and then do it. Yeah, man, 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, you came up with the, you know, .md on the end of a URL. So we didn't close the loop on resend .com slash pricing .md being a markdown render of that page. What other particular, I wouldn't call them tricks necessarily. Maybe the things you're standardizing around that are like, okay, yeah. When we build a CLI, a CLI has to have these particular feature sets that serve an agent.

Like what are some things you're doing? Man, the CLI was one where I spent a lot. I'm glad you brought that up because I spent so much time on that one. I wanted the CLI to feel good for humans first. I knew that, okay, there's all this talk about agents. That's great. But if we want to show perceived value on the product, we got to show on the CLI as well.

So the default way you have the interactive mode. It's beautiful with colors and different ways of inputting data. Just really, really cool. I love it. But we do need a non -interactive mode for every single command. We should have different formatted outputs as well. So if you don't want like a plain text, that's not really, you cannot really massage that output.

We have like a JSON version of that. And then I remember like, okay, I remember shipping that JSON version. And then I saw how agents would always do like that pipe GQ command to extract data out of the output. And then ours was failing for, I don't really remember. Like there was probably the way that JSON was formatted. I think it was a, oh, I remember now.

We would return like the data or a possible error in an array or something. And then it will always get confused. So then I changed the shape of the object of the output to make sure you could pipe the result. So just going over those things like, okay, how you can make your CLI actually good. And then actually discoverable. You got to put in every single registry you can imagine.

The updating system needs to be easy to use as well. Refresh tokens. And now like one area that we, going back to the importance of the primitives, we wanted to make off as easy as possible. So the permissions and the roles you'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. So obviously enterprises want as well, but users want that. So now we have to go back and rethink about permissioning and roles and scopes for all of tokens for API keys. So you cannot, every time you try to skip something and you're like, oh yeah, we can probably get away with this or we can simplify here.

Think again. Like, yeah, right. You know, it's hard. How much has this been a thorn in your side, so to speak, with like -based access controls? I know that you're a prior WorkOS employee and friend of Michael Greenwich, so I'm sure that you have just an unlimited account. I'm just kidding. Some sort of blessed way to just easily get WorkOS, right? WorkOS solves a lot of this to some degree.

But WorkOS isn't for really everybody, necessarily. Maybe it is. Maybe it's not. Like, how do you handle this problem? Like, it's not an enterprise problem. It's not a crossing the chasm problem. It's an enabling that we don't want to have to build off, but also get it right for the future the agents demand from us. Yeah, it's really tricky.

Like, the build versus buy decision is always hard. For the all -off layer, for example, we considered using WorkOS. We ended up not because we felt like this specific part, we actually have to own it. But then there are other parts, like the permissioning, the roles. I think we could use something. We're still exploring. We haven't solved the problem yet.

But it's always a battle of like, what are the parts you own, right? So I have a friend, for example, who's building a really cool API platform solution where you can provision the API keys there. And I'm like, okay, this is awesome. But man, we are a company that we sell API keys for, you know, to make money. Like, They are a super important part of the business.

I cannot just give that to someone else and then that's another round trip. It's going to make it slower. If you're accessing the website in New Zealand might not be the best performance as if you're somewhere else. So you've got to think about all these things and then decide, like, okay, yeah, this part we're actually going to 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 going to give up is like, man, it needs to be easy. It needs to be.

Yeah, like you should have those. Abstractions to make things more accessible for folks who don't have the time who are trying to set up email on a Sunday afternoon while the kids are running and they only have like 10 or 20 minutes. And if they don't get it right in those 10, 20 minutes, they're going to go away. They're never going to come back.

You're not going to, you know, you're not going to have another chance. Yeah. Do you have it where an agent can just discover or be told to discover, resend, and learn how to create an account? Like, what is does that exist today for you? Account creation is tricky. So we haven't really, because of the free tier and the abuse vector that that would create.

But we invest very heavily on like LLMs .txt, LLMs .txt. We had that in our docs forever, thanks to Mintlify. But then on our marketing website, we started to do that in every single page too. So you go to the most traditional marketing page you can think of, and you put a .md there, like you get a friendly markdown version of that page. We haven't done that for every single page, but for the most part, like all the blogs, all the handbook articles, all the change logs.

So the pages that we feel like they matter the most, content needs to be easily accessible, right? So we change like pages to have like an FAQ at the bottom of the page. That's the way people are asking questions. So let's try to make that a part of what we do. We, we, yeah, we did a lot of things that we've been using Profound to detect the requests that are coming in.

What are the citations? Okay. So let's figure out the citations because then that's how we can actually improve the quality of the response.

What if, uh, this is just me thinking out loud because I love problems. I just love, seriously love, I love problems. And as I'm listening to you, I'm thinking like, what if, uh, 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. Cause 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, cause you have more agents now that have an email potentially cause they're trying to get it or a credit card. Cause there's somebody trying to crack that nut. But like, what if, uh, you know, I knew like, Hey, I know resend, right? I'm a user of resend and my agent, I want to automate this next, 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. 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, uh, from that? Um, there are many deliverability constraints of that, but what if we, we did that right for the right people? Uh, I'm like super inspired by the outside world, right? I like, I, I, I love TSA pre -check and I love global entry, for example.

That's right. So, you know, those programs, you have to voluntarily pay for them and you've got to show up for an interview. Guess what? After you do that, your life is completely different, right? Way different. It's like a cheat code that everybody can have, but nobody does. Oh my gosh. It's the best thing ever. Uh, if you're listening to this and you live in the U S please get that thing, pay whatever you have to pay to get it.

It's like 300 bucks or something. Um, 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. Um, 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, uh, this was like, when I think Opus 4 .8 got released.

I'm like, Oh, I got to try this thing. And I went to, uh, YC, they have like this internal social, um, social channel there where you have, you can go. It's like your, their internal Facebook, uh, of some sorts. It's an internal community. Only company, only founders can go, not even employees of YC companies, only founders can go. So they really try to protect that place at all costs, but they have like a missing thing where you can push like information about your company.

People can mark that they are using that. So people mark that they are using recent, they can give comments about how they're using recent. And I can, I never get notifications about those comments. I would love to see it. Sometimes there's someone saying, Oh, I had a hard time redeeming the coupon. Okay. Then I can just fix that. So what I did was I gave my agent, like go to book face and scan all the comments on this page every single day.

Give me the sentiment so I can act on them. Um, so I just set up that, uh, that automation. This is me as a trusted user, giving my agent access to do this one task for me. Uh, and then I go to bed next morning. I wake up an email from YC. Hey, we're seeing that you're trying to like scrape data out of YC. Like they look at the IPs and it was a mismatch between the IP that I logged in and this other IP.

Uh, and then I get like a warning, like, Hey, you've got to stop this. Otherwise you're going to get banned for life. So like, but 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 got to really rethink about how the extension of our agents.

Like I was inviting five different users to our linear workspace, but they are not humans. They're agents. And I have to pay for an extra seat. Like seat based pricing to me doesn't make any sense in this new age. Uh, I'm glad we've never did that with recent, but man, yeah. There's so many things we got to 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 has gotten a lot easier to produce. Uh, still, you know, still out there, whether or not it's all good or not.

I don't know. Where are you at in terms of things? Are you 100% code generated in terms of you personally, corporately as recent? Are you AI maximalists? Everyone can write whatever they want as long as it's with an agent. Not token maxing, but are you all for AI in every way? To help resend? Yeah, I think it's my job to be pushing that inside the company because it is a big unlock.

And anyone who says it isn't, I don't know where they are living. I feel like it's a completely new world. I do hate the token maxing strategy, but I love the rethink what you're doing strategy and see where AI fits. That fits into that, right? And I'm kind of like obsessed with the whole loops engineering or factory engineering thing right now.

And I'm building like right now, I haven't even shared that with the team yet, but I'm building some of those loops that I feel like are closed loops. So there's one that I built that I'm using co -work to do that, where it goes to all the down votes on our website.

And then I'm using the in -app agent. And then sometimes they're sending. And then sometimes they're good, sometimes they're pretty bad. And that's why I haven't really unleashed to the outside world yet. And I'm trying to imagine like what are those other mini factories that we could build, right? Like that we can close the loop. Maybe one agent is sending the PR, the other agent is reviewing.

And we do that every single day or every single hour, every single minute.

But it's crazy how we went through the whole journey of, okay, the bottleneck are developers. We got to hire more engineers. Then the bottleneck is now PR. So we started sending a lot of PRs. Our repo used to have like 40 or 50 open PRs at any given time. Now it has 200. So, okay, it's a new volume of PRs that are being open every single time.

Then the bottleneck became the review process. And then we are like, okay, let's put AI on the PR. So we added cubic, bug bot, all these bots. We tried like all of them. And then the bottleneck became the CI. Like the jobs were failing or like taking forever to finish. And then like our compute was also like, we didn't have enough compute.

And then we have to change CIs. Man, the bottleneck keeps shifting, right? And it's fascinating to follow that. You got to 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 IDE. Oh my gosh, I did miss that. Yeah. What can you do? What can you do? Yeah, you can't fight entropy.

It's going to 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 few more minutes here, but one question I'd like to ask, especially whenever I feel like the person's got something up their sleeve, closer to the end of the show is like, what's on the horizon? And maybe it could be something that no one 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. It's hard to say one specific thing.

And maybe what I will say is connected to that other point of like, you got to be challenging the way you work every single day. Now, unfortunately, it kind of sucks in a way because you're, you're getting used to one way of working. And now there's a whole new wave of things. You got to adapt and you start, uh, you know, learning and, 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 CEO, as a founder, where do I deploy my energy?

And it doesn't seem like there's, um, like in the past, I remember it was always like, Oh, now I got to learn a new JavaScript framework. Ah, 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. Uh, 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? Um, where do you even spend your time? Um,

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. Um, so I would just encourage everyone to keep digging into their way of working and, and seeing like, Hey, let me try this. And then it's not good. Maybe it's not good right now.

Then, um, and then six months later, it's good. So assume that it will get better. And if it will get better, how would that change? How you do work today? Yeah. Yeah. Are you all hiring? Yes. What kind of hiring are you doing these days? What is it like in, in two minutes? What is it like hiring today? Like, uh, the peaks and the valleys and then specifically like who you're trying to hire for? First of all, so much noise.

Oh my gosh. All these fake resumes and all these, uh, weird things going on. Uh, but we are trying to assemble like the Avengers of the email industry. Like, uh, we just hired like a guy that came from MayoChimp that spent the last 10 years there, um, 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.

Um, so a lot of emails, 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. Mm -hmm. Work anywhere in the world? Yes. Or only in the self? All remote. No, all remote. We don't have an office. We don't plan to have an office. Super small team, 45 people. Most of them have like engineer on the job title.

Um, maybe 30 or 35 of them have engineer on the job title. Mm -hmm. So we're very engineering focused and engineering driven.

Right on, right on. Well, as you know, I'm such a big fan of you and the work you've done.

Still to this day use Dracula. Still to this day. I really do. Like I got my my Zed is so awesome because I have the plethora of, you know, from Van Helsing to Alucard, which I don't use too often, but every once in a while I got to go to the to the light. But but I think it's a Mobius is my Van Helsing, I believe, is the one I use most frequently and Mobius.

I'm more of a dark mode and then the green mode dark mode to which the thing is, if I recall, it's Mobius. I could be wrong. Yes, it is Mobius. Mm hmm. I'm a big fan of that. And, you know, so you're you're a little DX layers just to light 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, no, man, like I'm still looking at the screen. You know, I still have taste. I want to stay hacker to the heart and be in the terminal, not in some sort of like weird amalgamation of an IDE that's now an agent IDE. I don't know. An AID.

I don't know. There's a lot of things happening out there, but I still appreciate subtle things like color. You know, really, I do. And I appreciate that. So for those of you who don't know, and this is buried in the lead here is is then is the creator of the Dracula color frame. Would you call a framework color palette? Color scheme. Color scheme.

Yeah. Yeah. Is it Dracula dot com? Do you own Dracula theme dot com? I've been trying to get Dracula dot com forever, just like Zeno dot com. But those are the things are hard to get, man. Yeah. Dracula might be the tough one, man. That might be a tough one. But but Dracula theme dot com. And you have Dracula Pro still is out there. You can still purchase Dracula Pro, right? Or is it not paid anymore? Yeah.

I'm being a big fan for for all these times. Love that. 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 gone deeper, further, longer, et cetera. But we'll leave it there for now, my friend. Thank you again so much for joining me. It's been good seeing you.

Thank you, Adam. Thanks so much. You know, one of my favorite people out there is Zeno Rocha. I love the way he thinks. I love his energy. I love his excitement for everything. And yes, I'm going to be at Resend Forward this week. Talking to Taylor Otwell in the building room live on stage. If you're going to be there, come say hello. If you haven't heard Resend launched inboxes, it is one of the coolest features out there.

If you need to create inboxes to send email, they've got you covered. I'm building something on it. And it's kind of cool. Of course, thanks to our friends over at Fly .io for having our back. Learn more at Fly .io. And of course, the Beat Freak in residence, Breakmaster Cylinder, bring those beats. But that's it. This show's done. We'll see you in the next one.

Win it. Win it. It really whips the... King of... Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.