# Building for Agents: Resend's Strategic Pivot

**Podcast:** The Changelog: Software Development, Open Source
**Published:** 2026-10-22

## Transcript

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 markdown version of the pricing page served through content negotiation.
And this week, I'm talking to Zeno, founder and CEO of Resend, about building for agents as seriously as for humans.
We discuss why following the RFC for rate limit headers matters more than inventing your own and why agents couldn't care less about his animated icons and keyboard shortcuts.
We also get into publishing your open API spec as JSON in the dot well-known folder so tools can actually find it, why agents demand granular API permissions, and the closed-loop system he's building that turns downvotes on resends in-app agent into draft.
PRs.
It's a whole new world.
And speaking of a whole new world, I'm going to be live on stage at Resend Forward on October 21st, this Wednesday, talking to Taylor Otwell live on stage in the Builder Room.
Learn more at Resend.com forward.
All right, let's do this.
Well, friends, I'm here with a good friend of mine, Michael Greenwich, founder and CEO of WorkOS.
Michael, off for agents.
I feel like this is burgeoning.
It's.
It's kind of happening all of a sudden.
What's the state of the world for Auth4Agents?
Yeah, it feels like Auth4Agents 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 Auth4Agents, 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 customer's Google Drive and connect it to Salesforce and HubSpot and connect to Slack and all this other stuff that they're going to use and do it in a way that's safe and secure and managed.
That's one type of auth for agents, kind of data access auth.
The other type is actually authorization.
It's like permissions for what the agent is going to go do because you connect it to all these systems, but then you say, what capabilities does it actually have?
How can I restrict the agent behavior?
so it doesn't go off the rails and go do a bunch of crazy stuff.
That's a lot of stuff we're building today.
We don't have a product announced yet for that, but we've been working on it.
The third, I would say, is probably the identity layer for agents.
How do I identify an agent by its name?
That's really coming from the enterprise identity systems that are out there.
If you look at Microsoft's Entra 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.
None of us were talking about OpenClaw weeks or months ago.
And that's a new paradigm I think we're going to see, not just within consumer software, but in the enterprise too.
So it's an area of very, very rapid development.
Well, it makes me think about...
Agents versus people, 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 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.
Resend.
That's the best, right?
Yeah.
We care about email more than others.
That's how I would describe it.
I mean, when I first, if I'm being a little honest, when I first heard you announce Resend, I was like, why?
And a couple 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, minutiae, slow to innovate, you know, like all these sort of like seemingly negatives, but yet you took it on and then succeeded, of course.
But just even you, like you were not in the email space necessarily.
Why obviously has email become the, I would say, epicenter of identity?
And then the epicenter of distribution.
And then the epicenter of you name it.
What do you 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.
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.
And I would see just like how usage-based businesses also grow over time.
And if you go after like a big audience, how expansion revenue also helps the business.
So just looking from those things from the inside.
And I was a complete outsider to email.
Like, man, I was, I still am learning on the job, right?
Like there's so many layers to email that are incredibly wild.
There's like an email conference that I went one time, like, wow, pretty crazy email conference, like only Like the people who are running the spam filters at Yahoo and Outlook, like it's just like, it's a crazy world.
And, but man, I believe those boring businesses, those ideas that seem extremely like, oh, why, why do we need another one of these things?
Like we already have so many different email services, right?
Like, and I just saw like, Yeah, there was an opportunity.
I feel like every 10 years or so, there's a new wave of tools and developers are looking for what's new.
So I saw that with SendGrid and Mailgun, like they all have been acquired by now.
So there's just a bunch of factors that made me feel like, you know what, I might not know anything about email, but I do know one or two things about developers and how they think.
I am a developer and I feel like I can just.
put myself on their shoes.
And yeah, to me, that's the most important thing, like being able to just have a lot of empathy with users.
I mean, you can tell that you're a developer, obviously, with, and 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.
is in the way that composes from the from the to and the subject and the body, of course, is the way it composes.
You've taken something that I suppose should be hard, but you've made it easy.
It reminds me a lot of Stripe even.
And you mentioned like SendGrid and others.
Stripe came about after Brainstry and several others were like already key major players and they dominated because they simplified.
to an API and they simplified to really, I would probably describe it as like core developer substrate when it comes to how you take and deliver payments.
And they took this thing that was kind of boring, still is kind of boring, except for exciting to make some money, right?
But they took this, this already had been done thing and global player.
Well, you know, the.
The place, when you think about sending money or accepting money or payments or anything like that, you think Stripe, right?
Totally.
And they were obviously a huge inspiration to us.
I remember going to archive.org and looking at their old landing pages.
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.
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 Stripe.
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 him.
Okay.
I was like, okay.
I'm just kidding.
Like, I wish I knew Jack.
I've interviewed him once, but that was about it.
But, you know, they're an also random kind of a way, but they've also just like dominated in good ways too.
But now they're being dominated at the hardware level, like the Clover.
And I can think of like two or three others.
I can't think of this very moment, but several other players have sort of stepped in their space when they weren't.
really driving it.
And, you know, Stripe just sort of stuck in the, we're going to provide the conduit, the API layer, and they really haven't ventured further than that.
I'm not sure of any hardware on their front, but I'm sure they probably does some collaborations, but I'm not sure of anything in particular, like, 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 Stripe user with Resend, 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.
I'll tell my friend or whoever introduced me to that person.
It's like, okay, so what do you think?
Do you want to try it out?
And they're like, I don't know.
It's like, no, you should go for it.
And then I would just send them the payment link.
And they would either pay at the call or like after I would like keep bothering them and say, hey, can you please sign up for my thing?
And then people would eventually pay.
So that was like, I could code, but I decided to go with a no code solution because I just simply didn't have time.
And then the next iteration, a few months later, we're like, okay, now this is obviously not going to scale.
We need something in the product.
So then we embedded those widgets that they have.
So that was great.
And then once we 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's why I feel like they are brilliant in the way they execute.
Talk me through some of the architecture from primitive up to usable product by a customer, for example.
Help me understand when you deploy to production, what exactly is Resend?
Is it multiple application?
applications?
Is it like ResendD running on a server via SystemD?
Are you in Google Cloud?
Like where exactly, you know, 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 limited amount of innovation tokens and we knew that okay where where do we think is the best place to uh 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 tayo wind typescript and react Great.
So we built that layer.
We made it open source.
We knew that we would never make money with that.
But that was a great way to get users at the door.
Then we're like, OK, how do we invest on a SDK first world, not an API first world?
Truly believe that.
So, OK, then we invested super heavily on the Node SDK, but also SDKs for .NET, Rust, you know, languages that would be.
You know, maybe not as used because they were either too boring or too new.
So we built those and then we had the actual service, right?
OK, we're going to run this thing, how we're going to do it.
And during the early days, we chose the tech stack that made us move as fast as we could.
So we chose and maybe I shouldn't name names, but we chose like the hottest deployment platform.
We chose the hottest database platform.
And we weren't choosing the boring parts of tech, just the things that would allow us to ship very quickly.
And some of those vendors, they actually stayed with us for the longest time.
Others, we just outgrew them.
And we had many cases of that, like the queuing system that we chose.
It was great until a certain point, then we had to move to another.
So at the end of the day, we do have most of our software running on AWS right now.
And there are parts of that that we are looking into either building more of that internally, others not as much.
We did rely on SCS, which is Amazon's email service, to get started.
And now we're 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, you know, We still use and love and so on.
Are you involved in the architecture then?
Like with Amazon Web Services, are you involved in like how your application is shaped there?
Can you just talk me through what is it like to deploy Resend?
Like you mentioned deployment partners, things like that.
Like if you had to today, like in this podcast, a fire broke out, you had to step in and do something.
You'd probably fire up Claude, maybe his codex.
you know, whatever.
Maybe your hand coding's still yet, I don't know.
But if you had to step in really momentarily to look at something, check a log, confirm something, and do a new deployment because of something, what is that process like for you?
Yeah, we use CDK a lot.
So in the beginning, it was all click ops 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 everything we had to like keep rethinking.
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 an email, when you open an email, we fire those events through SNS.
We use Datadog so heavily.
It's definitely like all the other startups out there.
It's probably one of the...
most expensive line items.
It's insane how much they charge, but it's insanely useful.
So we have SLOs for every single part of our infrastructure.
But we do have like Vercel in other places too.
So our dashboard, our marketing website runs on Vercel.
We try to use TypeScript everywhere.
And I was like holding that fort for the longest time.
Like, you know, we're a TypeScript company.
But then it comes to a point where That language is not the right fit for what you're trying to solve.
So we have one piece of the infrastructure, which is the actual pipe when we're sending the emails.
And we rewrote that in Go recently, like three or four months ago.
So those parts are way more scalable right now.
But it's all very modular now.
Can you share some details about that Go rewrite?
Like what was involved?
Like what does the pipe do?
Why did Go make more sense?
Was it probably the binary, right?
The ease of reasoning about a binary is pretty simple.
How to deploy that is pretty simple.
You know, a lot of good things about that really.
Yeah, so there are two different ways of sending email at Resend.
There's one where you call the API or send in one email.
You just...
go, right?
So we queue those emails.
So even if the database is down, we can retry them later, all that kind of stuff.
But those ones are fairly straightforward, right?
You can also schedule an email.
So there's that aspect that we have a scheduler that we could run, but that's still fairly easy.
When we send a broadcast, which is this thing where, okay, I'm sending 10,000 emails all at once.
How do I do that?
So We found that if you just send 10,000 emails all at once, Gmail will look at that and be like, huh, this is weird.
Like why you're sending all of that volume all at once, right?
So what every single email platform out there in recent does that too, is that whenever you're sending a big batch of emails, you have to separate and break down those batches into mini batches.
You have to space them out as well.
And depending on the size of the audience.
So if you have.
300,000 listeners and or you have like 3 million, you know, we need to like space those out so that you're not going to be trottled by Gmail, which is what happened.
Gmail looks at those emails that are coming in and they might say, you know what, this is way too much.
Like I'm not going to place them on the inbox right away.
Let me see the first ones.
And depending on that, I might move them to the right place.
So.
That part was really tricky because you have one customer sending 5 million emails, but then you have, I don't know, dozens or hundreds of customers sending 5 million, 300,000, like all at once.
And we were struggling with concurrency with Node for all those batches.
And so it was tricky to handle that.
And Go is much faster with concurrency in that sense.
Yeah.
I'd imagine, how does it work to batch those?
Is that something that you give the user the choice of?
Or is that a smart layer of the platform where the platform understands how to shape things to your S&S partners, etc.?
How do you solve that problem?
It's a smart part of the platform.
So this is something we do behind the scenes to protect you as a sender.
Some people are like, oh, it sucks that I have to wait four hours for all my emails to be sent.
Three million emails.
I wish they would all go at the same time.
Of course, you do wish that to happen.
But at the same time, if you do that, you might have all of your emails landing on spam.
So it depends on the shape of how many emails you're sending in the past.
That's also important.
So there's a lot of little things that we might do to improve your deliverability that if you were to just move them and send to those inbox providers, they would just either throttle your sending, which is what Gmail does very often, or send straight to the spam folder.
When you fit this Go application in, how did you have to completely deprecate and remove something from the system?
Did you have to just gracefully, you know, blue green it?
How did you approach the swap?
And have you swapped?
Did you swap it over yet?
Yeah, we did.
We had multiple false starts.
Like we would try to go with that.
And then, oh my gosh, something broke down the line.
The shape of the email body and all the headers, because we were building this new system, like maybe someone would send an email with like 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 languages, 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, you know, enjoy, I suppose, maybe it doesn't enjoy it, is the intentional determinism when it comes to like Zod and schemas and types and things like that.
So like all that the TypeScript does, the agent doesn't need to remember the types, but it does need that system to remain sort of like guard railed.
So it doesn't have to do these wrong things or the right things.
And so I tried to choose TypeScript first, but.
I find that more often than not, the better shape for almost everything I want to use is a simple binary, is literally a binary, not a bunch of files that I have to then deploy and maybe compile if I'm using Bunt or something like that, or make it executable if it's, you know, Note or something like that.
So like just different things like that.
You know, I find that Go really is the better fit in almost every case.
I really just wish that Go had a better web story.
Like once you get past the system, the API, you know, all those things 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 don't want one choice, but it is, 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 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?
The software development lifecycle, right?
Like now you don't necessarily have preview URLs as you used to in certain parts.
Thankfully for this part of the system, we didn't need that.
But you start getting to those things like, oh, people simply don't have Go install on their machines.
So now, okay, let's teach them how to do that.
So there's little things like that.
And we use Docker, 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.
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.
You know, what a moment where now we can automate so much with it.
And so I thought it was kind of funny in a way that here in 2026, you would announce an official CLI as if like 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 all the entire infrastructure as a service category, I would say benefited from, 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 open AI.
They, 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 cloud code, cloud code work as my operation system.
I do work from that and having those integrations in place is super important.
And then the tools that don't give me that, I'm like, I just can't use them.
I'm like, I 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 was kind of the comical thing here is here we're in 2026, officially having a recent CLI.
What took you so long?
Were you just too busy?
I know in three years time you got so much to do, but seriously, why did it take you to this year when the boom happens to make an official CLI?
That's a great point.
We built CLIs over time internally, like during hackathons and stuff like that.
But I've always felt like, man, who's going to want to send an email from...
the terminal.
Like we are trying to help businesses to send, you know, transactional emails, reset password, welcome emails, like whatever you need to send, right?
Usage emails.
But would someone go and like spin up their terminal and try to send an email from there?
My feeling was like, oh, maybe not.
But it turns out you need all these other tools around it, right?
Like you're configuring a domain, You are looking at your logs.
Those things are extremely valuable to have on your terminal.
And then when this whole craziness happened, we just had to build one.
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 open source contribution rather than just deployment or build or performance necessarily.
Yeah, it took us a long time and it took us a long time to ship the MCP too.
With MCP, what was hard was we built the MCP server, we made it out there, and then all the MCP clients now require like an OAuth authentication method by default.
So we had to go back and say, okay, now let's revisit our whole authentication layer and how we save every single request, how we do everything.
to support not just a single way of authenticating requests for an API key, which is what we had.
Put your bearer token on your headers, you're good to go.
And we had to rethink the whole thing, deploy the whole thing, think about like auto trailing and observability for MCP service, which is a new thing that's emerging too.
And then now finally we push up like a hosted remote server.
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 you have all these different things you'll have to build to actually solve user issues as well as improve your interfaces.
It's crazy.
It's just so much to build.
What does it take for you all to receive an email?
Of this list, the things that really stand out to me is receiving an email, broadcasts, and automations.
But that's just my take.
Yeah, receiving is tricky because first, just the setup can be tricky.
You add an MX record, but then if folks use Google Workspace, now there's like a competition between the priority of the MX record.
So you got to deal with that.
You got to teach users how to deal with that once there's a conflict.
So that was one challenge.
And we think a lot about friction.
That can be an action that if someone is just distracted and they try to set up in a way, they might break their whole organization and they don't even know, oh, my emails are not, you know, I'm not getting any.
There's no observability for you to, you know, for like, oh, I broke my MX record ordering and now things don't work anymore.
And I can't even tell you it doesn't work because I can't receive or send email.
Oh my goodness, man.
It's insane.
It's crazy.
And then with receiving.
you don't really have control over what you receive, right?
You do have control over what you send, but what you receive, it's a wild world out there and people are sending spam to these wildcard usernames, support at whatever, security at whatever, sales at whatever.
So you got to do that too.
And you're just like, you're walking around out there in the marketplace, Zeno, with a target on your back basically.
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.
we were like, okay, looking for use cases internally that we would 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.
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.
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 were in five or something.
And then we just kept like building that V0 of inbound.
The reason why I love doing that is because you have to make so many trade-offs as you're getting started and you're in the room.
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 I'm like, that's why I'm like, no, I go to my Dracula domain, which I do use at Google Workspace.
And I'm like, now I have to configure these DNS settings?
Okay, but, oh, the conflict.
Oh, what do I do now?
Like, I'm lost.
Like, how do I overcome this?
So that's why I love having side projects until now, because I can always use them to feel that empathy.
Is this mainly giving, I don't want to just say like an agent.
We've said an application in the past, but I feel like now, our application layer kind of has an agent to some degree available or nearby.
Is inbound about handing an email address specifically to an agent or an application layer?
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 Tripsy.
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, okay, now I need to set up an inbox.
I like that use case.
We're building around that too, but it's a less frequent use case.
It's something that the volume is not as much, but still a pain.
So it's hard because we're trying to solve the problem for both.
There's the wild card solution, which is what recent is right now.
You set up inbound.
Every single domain, doesn't matter the address, it goes there.
Now what we're actually building, and it's looking really, really cool.
We haven't shipped that yet, but it's a full in-box UI for you to interact.
And obviously this UI will come with its own.
CLI and MCP server.
Well, friends, I'm here with the CTO of Buildkite and one of the most challenging problems of modern era software development is continuous integration and continuous delivery.
And so Lachlan Donald, 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 5 or 10x our throughput this year or 1,000x it, what breaks and when?
And, you know, my answer is kind of same as it's been for the past 20 years, which is that the bottleneck is still trying to integrate those code changes in and then...
deploy them and check they work and then keep them working as you keep throwing more and more code at it.
I think a lot of the fundamentals are the same, but we're just 1000xing the speed of it.
And, you know, that changes nearly every variable.
Yeah, for sure.
Okay, so where does Buildkite thrive?
What particular type of team or enterprise do you thrive in?
The area that Buildkite has always thrived in is like this like fastest moving tech companies of the world.
disproportionately successful in that small niche.
The kind of Shopify class, Uber class, you know, OpenAI class of folks that have this key problem around iterating really, really fast.
And, you know, the 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 our system in this tension where, you know, you've got to spend some time assembling those building blocks, those Lego blocks to get the thing that you want.
But the end result is far and away more performant and scalable and the experience is better than what you get from something that's off the shelf.
So I think we've started from a position of really well engineered logo blocks and then are kind of working backwards towards kind of creating the thing that scales down to a startup that starts with one person and 10 agents next week.
Well, friends, go to buildkite.com.
That's build.
Kite, 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 were 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 them, maybe you hand them your hand if they're going to take a fingerprint, that's weird.
So you can identify that way.
But the most common way we do it today in society is with a driver's license identification.
That's an API key, right?
It's got a driver's license number on there.
You 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.
Right.
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, like 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 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 you 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 the outside of the critical path, right?
So there are adjacent things that we could get into, but so far it's been, man, we just got to focus.
Like there's just so much to do.
Those 3 million users are asking for so many things here.
Let's just stay in our lane, at least for now.
We are obviously expanding the footprint of the product, but we haven't taken that extra step to go into a completely different vertical.
So those 3 million users are probably pretty, to some degree, vocal.
I'm sure there's at least one third, maybe one fourth that are more vocal than the other 75%.
Maybe not.
I don't know.
What are some of the things that they're telling you that makes you know, like give you assurance or some version of assurance that we're going the right direction?
Because when you have a swath of, a large swath of users telling you which direction to go, you kind of...
You kind of should listen, right?
And so are they saying, I want identity with my email?
Like, what are some of the things that they're really pushing you towards when it comes to product?
I hear a lot like phrases like, oh, I want a reason for a WhatsApp, a reason for SMS.
Twilio sucks.
Can you please make my life a little bit better?
You know, and.
SendGrid is now completely folded into Twilio.
They're rebranding as Twilio email and it's inside their dashboard.
They're taking off the domain and everything.
So Twilio is our biggest competitor and it's hard not to look at them and be like, you know what?
They're just adding more friction and we're all about making things easier.
Their SDK is not as great as it used to be.
So there's a lot of things we can make it easier there.
So there's a lot of push towards that direction of like, okay, recent is great for email.
How can it be great for my entire communication portfolio, right?
If I have to send messages, it doesn't really matter which channel.
Email could be one channel, but I'm just trying to get to users.
It's a comms channel, really, right?
Like a comms gateway.
They want one place to go, one API to call, one dashboard to look up, one log to reason, et cetera.
Exactly.
And I feel like that's the future for a reason.
I think at some point we'll get there.
But time and time again, every time we went to this road and we could turn left and go deeper into the email space or turn right and open a new channel, we always...
turned left.
It's crazy how deep email goes.
It's insane.
I'm always amazed at how much there is to build still.
I'm sure we have a roadmap for the next 10 years easily.
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 and you just, 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, it's all for nothing.
We could have the most amazing open handbook about how we operate, but if the emails are not landing, if the servers are down.
So that's where we try to spend a lot of our energy.
Let's make sure we have a solid foundation.
We started the company thinking we were building a DevTools 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 utility now.
Yes.
People call you, they expect you to answer quickly.
Every time.
Every time.
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?
You expect it to be there.
Where is my resend?
Totally.
And for some apps, it's like, it's okay.
I'm just sending a marketing email.
It's fine.
For others, no, my users are not able to log in.
You guys are letting me down.
There's no way.
So then we have to jump super.
quickly.
And we have a big success team by big, I'm talking five people.
But we are trying to be spread in as many continents as possible.
We now have people in APEC, like New Zealand, we have people in South Africa.
So we need that kind of distribution.
We cannot just be isolated in a single region, even as a team.
We're a team of 45 now.
It's a pretty small team still.
Yeah.
I don't want to ask you this question with a negative, but I'm going to do it just to get a reaction and just to dive in a little further.
But like, is 3 million users a lot?
Is that a lot?
I know it's a lot when you go from zero, when you have zero strangers using your software.
You know, I get that that's a lot of users, but like, is that really a lot in the grand scheme of the space you fit in?
you know, with SendGrid and others, like just changing around the scenes.
Like you seem to be the most, you know, Stripe, API, amazing DX, I would say maybe even now borderlining amazing AX, Asian experience.
Is 3Main a lot?
Is that a lot?
Yeah, that's a good provocation.
I saw recently that Superbase had crossed like 10 million users.
That got me thinking, like, oh, is this the TAM for developers?
Is that how big it can be?
I forgot now, but on the Twilio website, it was also around that.
So I'm like, okay, how far can we even go?
To me, what's interesting is like the definition of a developer is completely different, right?
So if we're building for developers, what really is a developer these days?
Crazy story, man.
I was at Vercel Ship last week in New York City.
And, you know, I was at the booth talking to people.
And it was great because Vercel Ship is different from Next.js Conf.
You can tell the vibes in the audience.
There's a lot of VPs and CTOs and CMOs, all that kind of stuff.
And during the afternoon, I had just finished lunch and a guy that was working at the catering company, he was like with some dishes.
He was walking around.
He stops me and he's like, oh, are you from Resend?
Oh, I use Resend.
I was like, no way.
Tell me more.
I even took a photo with him.
He's like, oh, yeah, like I'm trying to learn how to program on the side.
And I use Lovable and I use Resend.
I don't use Resale 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've 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 aha moment is too...
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.
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 meadowandhyde.co, for example.
And when he told me he built his website with Bolt, I think it's bolt.new.
And he said that he sends his emails with Resend.
I was like, what?
Same thing with you after lunch and this fellow.
It's not that they shouldn't.
It's that it's peculiar now.
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's not really a developer like you would consider a developer in the past.
Meanwhile, he's built, if you go to meadowandhide.co, for example, you will see a really beautiful website.
Well done marketing message.
Very clean and clear using recent, of course, as you know.
And I just think it's so wild.
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.
In this case, maybe it's your ability to access something.
I don't know.
It's a key.
It's so interesting in this world to explain what an API key is to people like, I don't know what you're talking about.
What does that mean?
It's just a key.
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 cryptography that's basically physical cryptography, which is like the shape of a key, for example.
And now we have people who would not normally be using API keys, requesting API keys, needing to have even a particular account type.
So you might be using a service that in the past, it's been pretty foreign for the user to ever ask you for your API credentials or to create a no auth to application inside the dashboard.
Now this question is becoming more and more the case where people need to do that.
And even having to have a particular account type to get access to that.
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 of lovable.
They're inside of 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 was like, what?
And he showed up to me.
I was like, dude, this is good.
Like, this is good stuff, man.
Like, it's not vibed at all, but it was vibed.
It was a version of vibe.
But here he is shipping products to people physically and using Resend to send the emails.
Like, that's wild.
So he's 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 also so beautiful.
And it's also super challenging too, because if you're one API key away from doing whatever you want to do, you can do a lot of bad things too, if you don't have the right intentions, right?
True.
We have a big challenge in, okay, we want to make it as easy as possible.
Great.
How do we deal with those bad actors?
Because there are weird people out there trying to send some weird emails and we block a lot of them and they keep coming back.
Now it's a different, nonstop.
It's a different version of that too.
Maybe last time, if we even talked about that subject, you know, 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.
You want to make it easy.
Yeah, but it's so tricky.
Like, for example, account provisioning.
I'd 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 thing.
This is not going to be here anymore.
So I just rip it off.
I rip it off.
This was like a Saturday afternoon.
I rip it off and I'm like, no, we're going to have bot detection on the login, but not on the signup.
And then you try to make things easier, but yeah, it's hard.
But then you see, you'll hear those stories and oh my gosh, it's just beautiful.
The power of, you know, 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...
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 that anti-abuse program internally.
We have so many systems that we're building.
You actually need a lot of staff to cover for this too, because abusers don't stop.
So it's hard.
And we were doing like an exercise in like, okay, think of like crazy ideas, go insane, moonshots, how we can make this one part of the company easier.
And for trust and safety, like one of the moonshots was like, oh, let's kill the free tier.
You know, in one second, we're going to like remove all those problems away.
You obviously create many other problems and it just doesn't...
really speak to what I'm trying to do.
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 as I was building, there were other...
The free tier is something that enables 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 3 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're still generous enough, right?
Like it's 100 emails per day.
If you're sending over a hundred emails per day, okay, maybe you have something going on.
So then, okay, now you can pay 20 bucks.
It's not the craziest thing, but still is for many people.
shut down that service or not.
I think for me, it's a dual thing.
It's both like a do good type of thing.
And we even articulated that if you go to our philosophy page on the recent website, that's the first thing that it will talk about, like make it for everyone.
So we talk about how there are developers, not just in New York or San Francisco or London, like, no, they live everywhere.
They have different access to the internet and the latest technology.
So we're trying to make something that can actually help and be used by a lot of people, even the users at the margins.
But there's just a fact, I believe, if you have a go-to-market motion where you're trying to win the masses.
The moment you gain that mindshare, it might be easier for you to gain enterprise mindshare later because now you have established name.
Now the models are recommending you.
So it was interesting to see that dynamic too.
Last year, January 2025, Lovable, Bolt, V0, man, those guys, they were driving so many signups to recent.
But our revenue was just like growing the same way.
January 2026, completely different because Claude OpenAI, they are recommending Resend, but those are actually paying customers that had the problem and we happen to be at the right place at the right time, right?
So it's a different type of user, but you shouldn't neglect them, even if they're not paying you right now.
That's a good point.
I mean, really it is.
I mean, you can scrutinize.
It's almost like long-term thinking versus short-term thinking, right?
Your short-term thinking is like, oh, free tier is bad.
Long-term thinking is like, no, actually free tier is 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 as CEO think about free pro scale enterprise?
Like, is it on the daily?
Is it once per week?
How do you think about your tiers?
Oh man, I think about them all the time and not, not daily for sure.
But, um, 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?
So in the free plan, it's like one domain.
And people are like, oh, I can't use recent because it's only one domain.
And then they try to create multiple free accounts to bypass that.
So there are things that you do to try to accommodate for one thing and then you lose the other part.
So I think about pricing a lot and positioning too, right?
So we could have like a cheaper first plan.
That's like people ask that all the time.
Oh, I wish like $20 is too much for me.
I'm in Africa and it's a lot of money, right?
Okay.
So let's make it 15.
Let's make it 10.
Let's make $5.
But then how is your product perceived the moment you, you, you change that too, 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, okay.
Pricing is a part of that too.
We messed up pricing so much.
I think we got it right with transactional emails.
With marketing, we charge per contact.
And in this age where you launch an app and now you have a million users out of nowhere, pricing per contact doesn't make sense.
So we are revisiting that too.
So some decisions we made because we're like, oh, let's just follow the market.
It's just easier.
We're not going to innovate in pricing.
Let's just mirror what's...
our competitors do.
I feel like that's a great idea at first, but now you realize like, oh no, what a dumb decision, right?
Like pricing is part of the product.
You cannot get away.
Look at any, ask any SaaS owner, what's their most access page after the landing page?
And they will tell it's slash pricing.
Like that's the page.
So it's part of the product and you cannot ignore that.
Well, on the copy front of your pricing page, it's stellar.
This is probably the most clear page I've ever seen in my whole life.
There's no fluff.
It is exactly what you'd want on a pricing page.
I'm not sure what role you personally played in this, but the slider of helping you choose which tier, like people want to know not just What do you offer and how can I pay you to get what you offer, which is 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?
So, you know, pick whatever metric you're comparing against.
Then obviously you're going to always have that enterprise tier on the far right hand side.
I feel so bad for those enterprise folks.
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.
If this could probably happen or these, you know, this is exactly what you're going to do.
Like if you're going to stand in the 500,000 range, you're probably going to be in the scale territory.
And to me, that's really cool.
Like how you've designed this page.
How do you see this page changing?
I know that I can't recall what it was.
I think I saw you do this where you just added a .md to the end of things.
I think, did you start this movement?
I said, no, I think this is you, right?
So how much traffic is this page getting that is non-human now that's still influential?
And how do you influence the non-humans?
How are you influencing these agents?
Yeah, that was funny because as you were saying good things about that page, I'm like, yeah, that page is good, but it's good for humans.
It's terrible for agents.
Yeah, 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?
And all that is maybe an API call and the response is JSON.
It's like, here you go.
Or maybe it's market.
Maybe it's actually markdown.
I don't know.
But anyways.
No, totally.
And the way I found out about that was, again, a Saturday afternoon, I'm just tinkering with stuff.
And then...
I asked like, oh, I was creating maybe a competitor analysis on Cloud and OpenAI.
I wanted to see what they would recommend.
And then they told me like, oh, Recent is the most expensive service.
And I was like, no, I know for a fact that this is not true.
And I was like so surprised and both of them got it wrong.
And then I was like, okay, let me uncover this.
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 request and then started to get the math right.
So what I did was, okay, I'm sending 2.3 million emails a month.
How much would I pay with Resend?
And then it would get the number wrong.
And then I was like pushing changes.
I was like, oh, 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, if you're not playing with your own product or if you're not like pushing yourself in the shoes of the users as they're considering your product, then yeah, like it will be impossible to uncover those things.
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 that's it.
So we're 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 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.
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 all the daily, you're not really going to discover the warts or the real potential.
You start to really like obsess and immerse.
It's almost like method acting.
You know, that's something about like in the moment is 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 gone.
You know, I don't know if you've seen that recently, but there's a pretty interesting song out 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.
I know we're getting close to our time here.
But, yeah, I feel like this space we're in right now, the way I think about things, I'm curious how you feel.
And I feel like, yes, as of January.
the table shifted, the whole world moved, and it's a new trajectory for almost literally everyone.
It is now this idea that you're not really building the feature for the human kind of you are.
You're doing it for human intent and human enjoyment, but the thing, the automation layer, the intelligence layer doing the work is the agent.
And I've always known you.
as someone over all these years really is to be someone who really focuses on developer experience.
And now we have agents and so we have agent experience, AX.
And anytime I'm talking to my agents, I'm always like, you know, this has to suit DX slash AX.
And it's always including those sort of two labels there to justify my 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 kinds 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 aging experience and resend and, and you have a whole entire blog post on this and, and all that good stuff, but like, what is it that you think about when it comes to aging 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 than if you go to any other dashboard.
Well, agents couldn't care less if your icon is animated or not.
I remember going on this huge project internally at Recent where Every form that we had needed to have a keyboard shortcut.
And you should be able to just submit using command, enter and stuff.
Man, I spent so much time with the team and agents couldn't care less about that too.
They see the keyboard shortcut, they don't need it.
So all these little things that you would imagine like, oh, they will help the agent.
They don't necessarily translate to that.
But there are many things that do translate.
So if you care about your API and making sure you're respecting the ATP verbs, if you have an open API spec that's important and 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 discovered by doing.
Yeah, I think it's the way to build these days.
You have to care about that.
And it's a completely new discipline.
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.
You try to get stuff done with your product.
We use this tool called 2027.dev where...
You give it an eval and then it tried to do an action.
So I tried 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 paste 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 Nikki 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 trap here.
And not only because the fact that it could be stolen, you could lose it, it breaks, and you're out of work while you're waiting for a new one.
But there's also just the consistency that you got there.
We all know developers.
Developers are going to be looking for some of the latest and greatest.
And if you're not really controlling how they get out there, that's where you get this.
It works on my machine.
It doesn't work in production.
It doesn't work anywhere else because you don't have that consistency.
You don't have that ability to really standardize what that environment looks like.
And this is a problem not only for new people coming in, you know, the onboarding statement is average, I think, is like four to five weeks for a new employee to really get their local laptop set up and ready to start doing their first time of code.
And, you know, the time to first commit is a metric that almost everybody knows.
And the reason they can't do that is because there's a lot of tribal knowledge out there.
They got to go talk to other developers.
What are we using?
Where do we get our dependencies?
Are we getting them from public?
Are we getting them from private repositories?
But there's also the security and the supply chain aspect of this.
When you have local machines.
out there.
Look at like the Shai Halud, you know, that virus that went out not long ago.
This was a compromise of the NPM public repositories.
They went and downloaded things.
NPM did what it did.
Next thing you know, you're compromised.
But when you use something like what we're doing with cloud development environments, then you can mandate and you can put restrictions on there to say, hey, you can only go get your packages from our private repo.
Those packages are expected to have been thoroughly vetted.
We know that they're clean.
Now, does this stop everything like Shai 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, is this agent experience is not just crafting a good experience, but when you hit the hurdles and the bumps, course correction, because that's when the turn will bound, right?
You'll come, the agent will get stuck and come back to the, the builder, right?
And that their literal, you know, prompt and response loop or cues or loops or whatever is the fad these days, right?
resend error 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 or your CLI responded in a way, it 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 where 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, great, resend's available again because the API limit's gone.
Like 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.
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.
They're not trying to hurt your servers or, you know, abuse your service.
They're just trying to learn how they can use it.
And so if along the way you have better milestones, waypoints, and just error responses, it's going to be a lot easier for that agent to get feedback from the system it's trying to learn while it's using it.
So true.
And man, we've learned that lesson the hard way in the sense that the primitives are...
The most important thing that matters right now, like getting the parameters 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, oh, a proprietary thing, because you believe that you have a better opinion than others, like the agent will know what to do.
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 it.
Why?
Like we do.
oh, they're searching for the .json version of the OpenAPI spec, not the .yaml.
I'm like, ah, now I have to build a thing that converts from yaml to json, deploy 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 .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've got to put in every single registry you can imagine.
The updating system needs to be easy to use as well.
Refresh tokens.
And now like one area that we...
Going back to the importance of the primitives, we wanted to make off as easy as possible.
So the permissions and the roles you'd give in the product, we just made it full access or sending only.
As simple as possible, you can start your API key with only that.
Guess what?
Agents want things to be as granular as possible.
Obviously, enterprises want as well, but users want that.
So now we have to go back and rethink about permissioning.
roles and scopes for OAuth tokens, for API keys.
So you cannot, every time you try to skip something and you're like, oh yeah, we can probably get away with this or we can simplify here.
Think again.
Like, you know, it's hard.
How much has this been a thorn in your side, so to speak, with like roles-based access controls.
Like I know that you're a prior WorkOS employee and friend of Michael Greenwich, so I'm sure that you have just unlimited account.
I'm just kidding.
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?
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 that agents demand from us.
Yeah, it's really tricky.
The build versus buy decision is always hard.
For the off layer, for example, we consider using WorkOS.
We ended up not because we felt like this specific part, we actually have to own it.
But then there are other parts like the permissioning, the roles.
I think we could use something.
We're still exploring.
We haven't solved 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 to make money.
They are a super important part of the business.
I cannot just give that to someone else.
And then that's another round trip.
It's going to make it slower.
If you're accessing the website in New Zealand, it might not be the best performance as if you're somewhere else.
So you've got to think about all 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?
We change pages to have 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 did a lot of things.
We've been using Profound to detect the requests that are coming in.
What are the citations?
So let's figure out the citations because then that's how we can actually improve the quality of the response.
What if this is me thinking out loud because I love problems.
I love, seriously, I love problems.
And as I'm listening to you, I'm thinking like, what if when an agent signs up, they don't have, like, obviously you have the pricing still yet that doesn't go away.
And you still have your account structures because you can't remove that from, you know, your user orgs, projects, like however you've mapped your world.
But what if?
When an agent signs up, they can only sign up for a paid account.
Like what if that, I mean, because you have more agents now that have an email potentially because they're trying to get it or a credit card because there's somebody trying to crack that nut.
But like, what if, you know, I knew like, hey, I know Resend, right?
I'm a user of Resend and my agent, I want to automate this next package I'm building for my ecosystem, for example.
And the package needs to send email or for some reason, the agent needs to get a new recent 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.
So, right.
Just take my money.
I love that.
And man, another big friction we have is like domains, for example.
So we do require people to bring their domains to be able to send email.
What if we just gave them a domain that they could just send from that?
There are many deliverability constraints of that, but what if we did that, right?
For the right people.
I'm like super inspired by the outside world, right?
Like I love TSA PreCheck and I love Global Entry, for example.
That's right.
You know, those programs, you have to voluntarily pay for them and you've got to show up for an interview.
Guess what?
After you do that, your life is completely different, right?
Way different.
It's like a cheat code that everybody can have, but nobody does.
Oh my gosh.
It's the best thing ever.
If you're listening to this and you live in the US, please get that thing.
Pay whatever you have to pay to get it.
It's like 300 bucks or something.
Man.
I love that concept of like you're coming in and you are voluntarily giving more information in order to unlock something else, right?
Like an added benefit.
So I've been thinking a lot about that too.
And that use case you described, I had that pain when this was like when I think Opus 4.8 got released.
I'm like, oh, I got to try this thing.
And I went to...
YC, they have like this internal social channel there where you can go.
It's like their internal Facebook of some sorts.
It's an internal community.
Only founders can go.
Not even employees of YC companies.
Only founders can go.
So they really try to protect that place at all costs.
But they have like a missing thing where you can push like information about your company.
People can mark.
that they are using that.
So people mark that they are using recent, they can give comments about how they're using recent.
And I never get notifications about those comments.
I would love to see it.
Sometimes there's someone saying, oh, I had a hard time redeeming the coupon.
Okay, then I can just fix that.
So what I did was I gave my agent, like go to Bookface and scan all the comments on this page every single day.
Give me the sentiment so I can act on them.
So I just set up that automation.
This is me as a trusted user giving my agent access to do this one task for me.
And then I go to bed.
Next morning, I wake up, an email from YC.
Hey, we're seeing that you're trying to scrape data out of YC.
They look at the IPs and it was a mismatch between the IP that I logged in and this other IP.
And then I get a warning like, hey, you've got to stop this or otherwise you're going to get.
banned for life.
So like, oh man.
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.
I'm glad we've never did that with recent.
But man, yeah.
There's so many things we've got to rethink.
Yeah, that's kind of the fun part of it too, right?
We get to rework a bunch of stuff.
And then thankfully with the reason for doing it actually helps us make it easier because now code's gotten a lot easier to produce.
Still, you know, still out there, whether or not it's all good or not.
I don't know.
Where are you at in terms of things?
Are you 100% code generated in terms of you personally, corporately as Resend?
Are you AI maximalists?
Everyone can write whatever they want as long as it's with an agent.
Not token maxing, but like, are you all for AI in every way to help Resend?
Yeah, I think it's my job to be pushing that inside the company because it is a big unlock.
And anyone who says it isn't, I don't know where they are living.
I feel like it's a completely new world.
I do hate the token maxing strategy, but I love the rethink what you're doing strategy and see where AI fits into that, right?
And I'm kind of like obsessed with the whole loops engineering or factory engineering thing right now.
And I'm building like right now, I haven't even shared that with the team yet, but I'm building some of those loops that I feel like are closed loops.
So there's one that I built that I'm using co-work to do that, where it goes to all the downvotes on our...
in-app agent.
It looks at those on PostHog.
So it uses the PostHog MCP.
Then it grabs that event.
It looks at the whole session of the user.
And then based on the whole session of the user, it sends a draft PR that updates the tool calls and the evals for that session to make it sure that, okay, the next session, this problem that happened right now, it doesn't happen again.
And then...
Everyday people are seeing like this one PR that I'm sending.
And then sometimes they're good.
Sometimes they're pretty bad.
And that's why I haven't really unleashed to the outside world yet.
And I'm trying to imagine like, what are those other mini factories that we could build, right?
Like that we can close the loop.
Maybe one agent is sending the PR, the other agent is reviewing.
And we do that every single day or every single hour.
minute.
But it's crazy how we went through the whole journey of, okay, the bottleneck are developers.
We've got to hire more engineers.
Then the bottleneck is now PR.
So we started sending a lot of PRs.
Our repo used to have like 40 or 50 open PRs at any given time.
Now it has 200.
So, okay, it's a new volume of PRs that are being open every single time.
Then the bottleneck became the review process.
And then we were like, okay, let's put AI on the PR.
So we added Cubic, BugBot, all these bots.
We tried like all of them.
And then the bottleneck became the CI.
Like the jobs were failing or like taking forever to finish.
And then like our compute was also like, we didn't have enough compute and then we had to change CIs.
Man, the bottleneck keeps shifting, right?
And it's fascinating to follow that.
You got to really, there's nothing you can do, right?
You adopt the thing.
If you ask me, do you miss that flow of coding?
That moment of like, it's you and your IDE.
Oh my gosh, I did miss that.
Yeah.
What can you do?
What can you do?
Yeah, you can't fight entropy.
It's going to happen.
Wild stuff.
Yeah.
A lot to dig into.
I'm sure we can go even further.
I know we got a few more minutes here.
But one question I'd like to ask, especially whenever I feel like the person's got something up their sleeve closer to the end of the show, is what's on the horizon?
And maybe it could be something that no one knows that you can share here today, but it didn't have to be.
What's something on the horizon that's upcoming?
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 getting used to one way of working and now there's a whole new wave of things you've got to adapt and you start learning and figuring it out.
But things are moving so freaking fast that you've just got to challenge any assumption you might have.
I'm challenging the assumption of who I am as a programmer, who I am as a CEO, as a founder.
Where do I deploy my energy?
And it doesn't seem like there's, like in the past, I remember it was always like, oh, now I got to learn a new JavaScript framework.
Oh, it sucks.
Like I was just learning Amber and now I have to learn Angular.
And now I'm just learning Angular, I have to learn React.
And that sucked, right?
Now it's like, it has nothing to do with the framework.
It has nothing to do with the technology itself.
It's like.
the actual way of like, how do you contribute?
How do you add value?
Where do you even spend your time?
How does that change your personal life?
How you eat, how you sleep?
Like, it's just crazy, man.
It's insane how you spend money.
Like, it's really, really crazy.
So I would just encourage everyone to keep digging into their way of working and seeing like, Hey, let me try this.
And then it's not good.
If it's not good right now, then, 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.
Are you all hiring?
Yes.
What kind of hiring are you doing these days?
What is it like in two minutes?
What is it like hiring today?
the peaks and the valleys, and then specifically who you're trying to hire for?
First of all, so much noise.
Oh my gosh, all these fake resumes and all these weird things going on.
But we are trying to assemble the Avengers of the email industry.
We just hired a guy that came from MailChimp that spent the last 10 years there working in deliverability.
So we're like trying to find these people who want to challenge this industry and maybe feel like the place that they are at is not really the place.
So a lot of email specific knowledge, but also if you're just a product engineer and you care about the work that you do, we're here for that too.
Mm-hmm.
Work anywhere in the world?
Yes.
Or only in SF?
No, all remote.
We don't have an office.
We don't plan to have an office.
Super small team, four to five people.
Most of them have like engineer on the job title.
Maybe 30 or 35 of them have engineer on the job title.
We're very engineering focused and engineering driven.
Right on, right on.
Well, as you know, I'm such a big fan of you and the work you've done.
Still to this day, use Dracula.
Still to this day.
I really do.
My Zed is so awesome because I have the plethora of, you know, from Van Helsing to Alucard, which I don't use too often, but every once in a while I got to go to the light.
But I think it's Mobius is my, Van Helsing, I believe, is the one I use most frequently in Mobius.
I'm more of a dark mode and then the green mode, dark mode too.
Which the thing is, if I recall, it's Mobius.
I could be wrong.
Yes, it is Mobius.
Big fan of that.
And, you know, so your little DX layers just delight my world every single day, man.
Like I really, and I'm thankful for, 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.
Nah, man, like I'm still looking at the screen.
You know, I still have tastes.
I want to stay hacker to the heart and be in the terminal and not in some sort of like weird amalgamation of an IDE that's now an agent IDE.
I don't know, an AI.
I don't know.
There's a lot of things happening out there, but I still appreciate subtle things like color.
You know, really, I do.
And I appreciate that.
So for those of you who don't know.
and this is buried in the lead here, is Zeno's the creator of the Dracula color framework.
Would you call it a framework?
Color palette.
Color scheme.
Color scheme.
Yeah.
Yeah.
Is it Dracula.com?
Do you own?
Dracula theme.com.
I've been trying to get Dracula.com forever, just like Zeno.com, but those are the things that are hard to get, man.
Yeah.
Dracula might be the tough one, man.
That might be a tough one, but.
but Dracula theme.com and you have Dracula pro still is out there, right?
You can still purchase Dracula pro, right?
Or is it, is it not paid anymore?
Yeah.
I'm a big and 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.
I've 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.
And 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, bringing those beats.
That's it.
This show's done.
We'll see you in the next one.