Automating Developer Email with MCP and Al Agents
44:39 Share

When you go to all these different apps, you go to Supabase, the majority of databases you see there were built by humans. You go to Resend, the emails were sent by humans or drafted by humans and then sent programmatically. I think we're going to see a big shift in terms of who is the actor, who is the creator. And I believe it's going to be the majority of the actions will be taken by agents instead of humans. And that's just the reality we're going to live in.

So we have to rethink the way we're building product to support that reality. Thanks for listening to the A16Z AI podcast. I'm Derek. And if you listened to the episode we published yesterday with A16Z's Joe Schmidt and 11X's Prabhav Jain, I hope you appreciate the double dose of us this week. This one featuring A16Z partner Yoko Lee and Resend founder and CEO Zeno Rosha is particularly fun and particularly timely. They also dive into the topic of AI agents, although with a much more developer-centric lens.

Hitting on the growing importance of building for age and experience, the rise of MCP as a connective tissue between AI models and products, and how the generative AI prosumer experience will translate into better designed and more quickly built email templates for everyone. And Zeno shares his harrowing story of hospitalization and laptop theft that resulted in the creation of the popular Dracula theme for code editing tools. It's a great discussion that you'll hear after these disclosures.

As a reminder, please note that the content here is for informational purposes only, should not be taken as legal, business, tax, or investment advice, or be used to evaluate any investment or security, and is not directed at any investors or potential investors in any A16Z fund. For more details, please see a16z.com slash disclosures.

Recently, we've been seeing a lot of agent-centric applications and then developers kind of utilizing LLMs to build net new experiences.

And then what's interesting is that a lot of the developers I met, they were like, well, nowadays, not only do I need to build services for humans where DX is top of mind, they now need to build experiences for agents. You know, as a founder in this space who's been building, you know, developer experience for, you know, all across the spectrum, what's your high level thoughts here? What have you seen?

Yeah, I've been obsessed with developer experience, you know, for the past 10 years. And now you can see that there's a shift and there's a new obsession for me when it comes to agent experience, you know, as a product, as a SaaS provider ourselves.

we are thinking about how we can make the product easier for agents to consume. So even like small things like adding reCAPTCHA on the signup to prevent bots, now you have to think, do you really want to prevent bots from signing up? Maybe you don't, right? And same as an infrastructure provider. So Resend is an email API for developers. It helps people send transaction and marketing emails.

So I'm also thinking a lot about, OK, how can we make the experience of these agents sending emails the easiest as possible? So there's a lot to uncover on each spectrum of product when it comes to making it more agent friendly. But it's fascinating. We're all trying to figure out right now. Agent experience is such an interesting term because like when I hear the term agent experience, I wonder, is this a developer experience but for agents or is this a developer experience that

better for the end human developers to build agents or perhaps it's somewhere in the middle. How would you define the term? I think about developer experience as the sum of all the little details. And that's what makes

either great developer experience or a bad developer experience, right? So for agents, I believe it's the same. You know, you're trying to build a world where agents are the first class citizens and you're

When you put that in perspective, then you have to rethink a lot of the different things you do. So as an example, in our industry, you go to SendGrid, you go to Pulsemark, to Mailgun, you sign up for these services. And the first thing you get is a manual verification process that takes two days for you to get approval of your account. Right.

In an agent-first world, that's simply not possible. An agent will never wait two days to take an action. So Resend from day one was all about removing friction, right? So you sign up, you can send an email in the first minute. When we built that, it was all because we thought this is a better product experience overall for users. Turns out this is a huge unlock for agents.

So I think it augments GX. It's not a replacement or anything like that. It's more everything you already do, for example, docs, right? The more you invest in docs and knowledge base, the more quality of the LLMs that you're going to have, like in terms of the output there. So

The things you do for one already help you for another. It's so interesting, especially that email is like a service every human developer needs, either personally or as part of what they're building. Because once someone signs up, you want to send them a welcome email, so on and so forth. So when I think about agents, what do agents need in the world of email?

Do you think of agents as users of the email? In the future, every agent will have their own email address and they'll process the email forwarded to humans. And or do you think agents will, you know, also kind of require a different level of abstraction when it comes to leveraging the service in a programmatic way? Using the analogy of autonomous cars, right? Waymo, they couldn't build new roads. They had to figure out a way to use the existing roads to transport

make sure their product would work. So I think the same for this. We already have APIs, we already have these established SDKs and protocols. So we're going to have to figure out a way to leverage those instead of creating everything from scratch.

But I do believe there are like fundamental differences and limitations as well, right? So there's a reason why llms.txt exists as a format because it's so much easier for llms to consume just

just plain text versus all the different HTML and React code together with Docs, right? All you want is the content. Same on the email world. Like whenever you're sending an email, you only have two formats you can send. You have HTML and you have plain text as well. And the plain text is like the old school format that, you know, people don't really care as much today. Turns out in today's world,

That's actually better than the HTML version because it's easier to parse. You're using less tokens. It's cheaper. So I do think there's a fundamental difference. And even the way you think about API keys and permissioning, is it a user or it's a service account? I think there's a lot of challenges in it.

You have to figure out a way to leverage the existing product surface. The LLMs.txt is such an interesting example because the fact that it exists is because LLMs just do better with this kind of information. And as a human, if I want to copy paste the entirety of a site, I wouldn't, you know, write a scraper to go copy it. It's very hard. I'll go to LLMs.txt and copy paste it and put it in my ChagiPT.

I guess in the case of email, because historically people have been sending a lot of like very pretty marketing emails to humans and humans react to that because we're very visual animals. Yeah. How would it change now if we're sending emails to agents? Yeah. Content remains the king. I guess the difference now is that we're going to be living in a world where agents are talking to other agents. Right.

And these agents are sending emails, but also receiving and parsing and sending to another inbox that is also powered by agents that's parsing, taking action and sending. So the more content focused these emails are, the less markup, the fact that if they have a plain text version of it, I think it's going to be a lot more

I think this is more important than ever. Yeah, that is so interesting. I've been thinking about generating applications, generating even like a CLI tool. I'm a huge fan of Cursor, so I use it every single day. At the same time, I keep wondering, what does it look like if I can incorporate other long-tail toolings I already use as a consumer or user?

to generate other interesting experiences. What's your view here when it comes to like, for consumers or consumers generating like, net new contents using AI? I think my view changed drastically two months ago when I was answering users who were signing up to Reset and I always asked them like, "Oh, like, where'd you come from? What are you doing?"

And this one day, people were just saying, oh, I came from Lovable. I came from Bolt. I came from V0. ChatGPT recommended you. Cloud recommended you. So I saw that happening like more and more every single day. And it was just so clear that, you know, there's a new world happening in front of us. And these prosumer apps, those prosumer

those text-to-apps applications, they're very interesting because they focus on this one vertical. They help this type of user build this type of website, for example. I think we're going to see that across the board for every single industry. There's going to be one of those. The output might be a little bit different, but you're always going to need something that is tailored to that industry.

So when I think about these apps, you almost see the same UI. You have a chat on the left, the preview on the right. But what really matters is what's the thing on the top right corner, like that button, the call to action. And for Bolt, Lovable vZero, it's publishing. It's going live with the website. That's the aha moment. It's not generating the code or building the to-do app. It's actually putting it live.

And I think, you know, there's going to be apps for each one. And that's the main part of each one. What's a new call to action if we think about the email world? I guess like when I think about email, I'll think about I'm either on the receiving end or on the sending end. On the sending end, if I'm a non-technical user, I want to make sure that things are, you know, structured correctly, sent to the right, you know, set of people. And I want to make sure they open the email.

If I'm a receiving end, I want to make sure that I get the information I want quickly or this is a joy to read. I guess in the AI world, how would you think about it? Does it change? Is it like the same set of abstractions we're kind of playing with just how it makes it more efficient? The challenge is always like sending the right message to the right person at the right time. So customization is important.

more important than ever. You see all these AI SDR tools and it's great that we're seeing a revolution there, but just customizing based on your last LinkedIn message, it's not going to be enough. When you're sending email, you have all these different challenges around rendering. So for an email to render the same on Outlook and Gmail and Yahoo Mail, you still have a lot of challenges.

So that's one part that needs to be figured out. And then the other part on the receiving end is, yeah, do I really care about this? And if I do,

is this email on the primary inbox and not the spam folder? Yeah. So there's a lot of challenges on both sides. Yeah. And then there are so many interesting experiences one can build with email, whether it's from a developer or a consumer. So as an example, like my husband and I, we built this app that sends emails to us and texts us when our cat jumps on the kitchen counter. Yeah.

And then it was like a lot of it was not much code to be written, but it's just a lot of joy to build because everyone needs to be notified of something. And I guess like in this example, from all the text to app kind of side of applications, what kind of fun experiences can you imagine that we can better empower consumers and consumers to do that's better incorporated with emails?

What would they be able to do that they may have discovered or what can they do that they haven't discovered? So in our case, you know, we started this open source project called React Email two years ago. And that project, the whole vision around it was, you know what, we need to figure out a way to modernize the way emails are built.

So it was all about like, how can we bring TypeScript and Tailwind and all these modern technologies react? Let's bring all that together to, you know, this industry that feels like it's not moving forward or not innovating as much. So we did that and it was great. A lot of people using that every single day. But now that we have LLMs, there's a new unlock. So this process that used to take days now takes hours or minutes.

But with LLMs, it can take seconds, right? And it can enable not only developers that need to know how to code, but these folks that can be just like, I'm a marketer, I'm a designer, I'm a product manager, and I need to send an email. So how can I do that? So we built this thing called New Email that really helps you go from zero, from an idea to an email template in seconds, right? I just see that happening across the board. Right.

So whatever the industry is, I think they will have a variation of that in a way. That's so interesting. In a way, like, what would be a great way for, say, if I'm a marketer or a designer, I want to send an email. What's the best way to leverage existing tools like new email or others?

to kind of send high quality emails. I remember this conversation I had with a friend of mine. This is a designer that works at Uber. And he was telling me how for the past two weeks, he didn't open Figma. He was just building all these prototypes using cursor, using vZero, using these tools that are now available for folks.

And for me, that's incredible. That's so amazing because it redefines what a developer is. I think that's exactly the same for email. Before you needed to maybe hire an agency and you would build this beautiful email template and then you hand off the Figma file to them and then

A week later, they come with this super ugly markup. The email looks good, but, you know, behind the scenes, like they had to do a lot of magic to make it happen. We can give that to LLMs now and empower the actual creator, the person who's thinking about the copy, thinking about the angle, because as a builder yourself, you know that when we're building things,

Like the first, you know, version, it's not always the best. It's just the beginning. So you see that thing working and you're like, okay, now that's working, what else can I do? And that back and forth, you know, between agencies and non-technical users, you know, it's just like wasted time that it could be just focused on that creative person that's just keep iterating on that until they have something they like and then they can just send it.

I love that. It really shortens the creative loop. It just reminds me that, you know, back in the days, obviously, like for oil painting, people like to throw some paint on the canvas before they get started because a blank canvas is super scary. I don't know what you thought. So a lot of painters, what they will actually do is to throw gray colored paint on the canvas and then they will use like a little bit of cloth to spread it.

And then they were like, okay, now there's a bit of color. I'm like less scared to actually make an action. This actually feels a lot about that. Yeah. Yeah. You know, it's funny. Yes, this is something that happened yesterday. So we gave this product, the new email product to a couple of friends. And then one friend was like, you know what, I'm trying to build something very creative, you know, but...

It takes me like a couple of prompts until I get something that feels different. Like the beginning is always, it feels the same. Like this too is always generating the same kind of emails. And that's because on the system prompt, we told, you know, the LLM to build Apple-like emails with curved borders and black and white vibes versus, you know, go crazy. And we thought we were doing a favor to include that because then the first version is,

good, but that also it's a constraint on the creative person that's trying to build something way more creative, you know, so it's fascinating. Yes, you need the first version to be there and then you keep iterating.

But if it takes too long for you to iterate, that's also not good, right? There's a balance there. That's so interesting. It really reminds me of in the image generation world, there are different lauras, training laura on specific styles, say impressionism.

And then the end user can select any one of these floors and then, you know, create the first generation of a image that's like these kind of styles they predefined. And then they can iterate from there. And then the rest of it is just the editing process. You need to have a lasso tool somewhere. There's AI versions of all of these now, right? And then the question is like, how can you morph that into something you like? Kind of like a sculpture, right?

So, yeah, this is so interesting. Email templates as very artistic expression, because before it was so hard for people to do this themselves. Last time I looked at email templates, it was all vanilla HTML. And I just remember thinking this can't be because this is 2025 now. Remember when I first got into the industry, it was like that. It just hasn't evolved much. So it's really great that you guys are, you know, creating a new experience, a different level of abstraction, too, for a new audience.

Yeah, you think about how much the web evolved as a platform and it's, you know, the problems that we used to have 10, 12 years ago around browsers rendering different websites, you know, that's gone. Ajax. You know, Ajax and like iCloud.

IE6 would render different than Opera and Firefox. That's solved. But with email, it's still a big pain. Outlook still doesn't render the same as superhuman, as Notion Mail. Like you have new email clients, you know, being created right now. Right. So it's still an open problem. Like people are still trying to figure this out. Yeah. Yeah.

Speaking of generating things, do you see the generation experience as an agentic workflow? How do you view that? Do you think you're building an agent? In many ways, I think yes. And then in other ways, I'm like, is this really an agent? What's your definition of agent? Yeah.

I think it's, yeah, and I don't know if it's the right one. There's no right definition. No one knows. Exactly. But I think it's just like a set of tools that are being executed and they're trying to accomplish a specific task, right? So it might take a few steps to get to that final result, but...

It's still like very focused on doing one thing. So I think like in the case of new email, for example, we have one agent to build the email template and then there's another one to actually send it or schedule it. So you can have like multiple agents running at the same time. But they are still very...

Focus on doing one task. Just, you know, in a company, you would have one person that does marketing, one person that does design and you're like assigning tasks to these people. What is your definition of

So my definition of agent is kind of like very similar to yours. I think of it as a multi-step LLM execution process. It's almost like a process in the systems level. The difference is that you have LLM in the middle to make the decisions and then the rest of it is very much technical detail. On the one spectrum, you can have a one-step generation process. You could call it an agent because that's what co-pilots are.

On the other spectrum, you could call AGI an agent. That's like an agent that reads and writes everything for you. Maybe you manage your bank account one day and email and auth and so on and so forth. So for me, I've been just, you know, as a fellow developer kind of developing the space, there are so many different ways to build agents. You know, if you're a platform, you're thinking about how can I make it easy for agents to visit us?

How can I make it easy for other people to build tools around it? And then if you're like a developer trying out certain tools, you're going to work with one of the platforms. The question becomes like, how do I easily integrate the long tails? I don't want to rewrite all the API calls all over again.

I guess, what's your view? What's your advice to developers who want to start building agents like yourself? Is there a standard today? Like, how do you think about this? Yeah, I think the emerging standard is definitely MCP. There's still like the question of is MCP going to be adopted by other AI models? And if that's the case, that will be an even bigger unlock than it already is. You know, MCP is on fire now. Everybody's talking about it.

Imagine if OpenAI adopts that, then it's over, you know, like that would be the de facto protocol.

But there's a lot still to be explored in terms of the different interfaces. So as an API provider myself, I want to make sure we have an MCP for resend so other agents can use that and send emails. They can look at their contact lists and take action, add people to the contact list, remove, see the performance of the emails they're sending.

And based on that, they can then decide, oh, this email is being clicked more than this other one. So let me optimize for that. So there's definitely things to explore around that. But it's an ever evolving ecosystem, right? There's no right answer yet. Yeah. And you see some like some people trying to build galleries of MCP servers and trying to create the marketplace for MCP. Yep.

That's also interesting, like the same way that when APIs came out, people were like rapid API. They were like, oh, let's build a marketplace of APIs. I think it's good to a certain extent. At the end of the day, I have a problem. I'm going to find whatever the solution is. So if I'm thinking about billing, I'm going to go to the Stripe API. If I think about email, go to the recent email API.

But the MCP format, it's extremely interesting. But we have to see what are the other interfaces that this is going to expand to. Just Cursor and Cloud Desktop is not enough. And that's what we have today, right? And WinServe, like these other editors, but...

What else? And I think if we get to the consumer layer, then it can be very interesting. Yeah. So there's obviously MCP servers. It's kind of a philosophical question now. Are you an MCP server? Are you an MCP client? Because you don't have to pick. What's your view on that? Do you think it's new email or recent? Both or one? Yeah, I think we'll be both. I can definitely see a world where

We are the MCP client where you can come in and say, you know what, get my top 10 linear feature requests and then draft an email based on that and then send.

So you have three different services running to execute that task. Or go to Notion. Like we are running all of our all hands meetings on Resend now. So it's like one email that we all write in a multiplayer approach. And then by the end of the call, we just send the email. So it's just super fun. That's amazing. And yeah, like I see that kind of like workflow where I'm like, okay, yeah.

Just go to linear, grab the tickets we closed last week, and then let's use that as a reporting mechanism or from Notion or whatever.

So, yeah, I think we're going to be both. So most of the use cases I've actually seen MCP today, it's very local first because of the nature of how the MCP clients are implemented. First, SSE is kind of a pain. So most of the people kind of default to implement MCP as a command. So as a client, the client basically just execute that command locally. And then that process can call into other third party APIs.

What do you think is missing to make MCP more of an ecosystem? I mean, obviously now it's an ecosystem, but what's missing from pushing it forward even more? I think it's adoption by the other models. I think that's the biggest one. There's so many different frontiers that MCP is getting to now that I love. For example, access to your file system, you know, to Apple APIs that are running on your desktop.

I've just seen like the latest release from Raycast where you're building all these AI extensions and you're integrating all these different workflows that run on your desktop layer, not in the browser.

As we keep exploring that, I think that's fascinating because we keep going down these different abstraction layers and having more access to do more things. So go to Apple Notes, grab my notes, and then do this other thing. I think that's fascinating and I hope that people continue to adopt. What's your prediction on the kind of MCP workflows that will take off? Obviously, there's a very productivity focus, like getting Notion, Notes,

put it in an email, send an email or send emails from cursor. It's everyday like kind of workflow. Do you think there are runtime workflows? By that, I mean like when a service is running and a CPE server will step in and do something. I actually haven't seen that happen in production, but just curious what your thoughts are there.

I think all of the system of records type of applications, they will be front and center at this new revolution because all of your issues are already on Linear. All of your emails are already on Gmail. All of your notes are ready on Notion or Apple Notes.

they're going to be in a very good position to then, you know, based on that information, do this other task. Interesting. So there's definitely a data gravity. I think so. To it. Yes. That's so interesting. Do you see most of the MCP related like clients or server around their own databases? Yes.

Wow. That's a good one because you need to store state, right? Exactly, yeah. Yeah, I haven't thought about that, but I think that would be a pretty interesting approach. I think when you look at, we're talking about this tax to apps applications, right? So you have Lovable, V0, and these apps, they're using different databases. So for Lovable and Bolt, Superbase, V0,

For Repl.it and Create.xyz, it's Neon. And I think the race with those is going to be around who can reduce friction the most, who can spin up a new Postgres database faster. So I think in a world where MCP is at the front and center, then, yeah, like how can we have these databases? There's, you know, they spin up so quickly, we can save state and then maybe we'll need a new kind of database. Yeah.

Yeah, that is very true. Obviously, I've been playing recent. It's always recommended by agents at LLMs because the distribution of the training data, I guess, there's just so much of that. Every time I ask ChatGPT, oh, I want to draft this email. And it just gave me a React email template right away. I'm like, how did you know this? Where did it come from?

When you think about more creative use cases developers can do either with agents, without agents, or some other LLM-driven processes with Resend, what comes to mind? You know what? There's just a lot of systems that developers rely on every single day. Like GitHub, you know, they are storing their pull requests in one place. But they also have branches that are running locally on their machines that they haven't pushed to a remote system yet.

The combination of desktop and web, I think that's beautiful. There's so many fascinating angles that you could do. I saw a demo last week where someone was using like a Raycast extension that was not powered by MCP, but very similar in a way when you look at the implementation. And it was integrated with Bob, like an HR system. So if we go to this HR tool and you would only ask, oh yeah, who is this?

celebrating a birthday this month. So based on those four people, let's draft a message that's unique about each one of them. Wow. Or look at the different interests from these people based on their Slack messages on top of, you know, this HR data. Yeah. So you can go, you know, there's so many interesting use cases where you can just

Pipe data from one place to the other, and then you can get something that's extremely tailored on the other end. I guess in the past few weeks to past couple months, what is the craziest use case you have seen that developers or AI developers use Reset for?

There's some really interesting AI generated newsletters that are being triggered for recent. I saw one last week where every single day they generate a new one and they send just the content is so interesting because you can fetch from so many different places. You get like the latest news from X and latest news from like different publications and then you put all together and then.

Here you have a newsletter that's tailored for you versus, you know, this big poll that you're trying to almost please everyone and you ended up not pleasing anyone. So there's something about that that I really love. There are people with thousands of domains in one recent account.

And they're spinning up new domains as new applications are built. So there's just very different. Spinning up new domains. Yeah. Can you do that on a recent? You can. Yeah. Programmatical. That's amazing. As in pre-warming domains or getting new domains? Yeah. So for example, Payload CMS.

Every time you sign up for one of their cloud products, so they have like this, it's like a WordPress alternative and you can just create a cloud version of it instead of deploying your own server. Every time they provision one of those, they provision a new domain powered by Resend and then email sending is already done for you. Like all the configuration, all the SMTP setup, everything.

The domain is there already verified. You don't have to add a DKIM or SPF record. It's all there. So from day one, you have email sending capabilities, which is something that traditionally was very hard to do.

I can't wait for the day when agents can have their own domain. Just thinking about how many agents side projects there will be that they don't utilize way more than humans. Maybe they will come up with like new project ideas and they'll be like, oh, let me see if the domain is free. Oh, yeah, it is. Bye. And then... Totally.

Yeah, as a human developer, this is just like something that I always love doing, even though I don't use. I probably spend hundreds of dollars every year just paying for domains I don't use. The other day, a friend of mine, he sent me a text. He was like, did you know .li is a top level domain? I didn't know that. It happens to be my last name.

And then Yoko is not a very common name. So I was able to get the domain right away. So now it redirects to my website or something. I tried to get the .no, which is the Norwegian PLG. I couldn't. Z.no, I couldn't get. But I'm still trying. Was it because someone took it? Someone took it. Oh, I see. Interesting. Well, we can write an agent to get domains. Yes. Just check every day if the domain is free and then let me know when it's free.

And then just buy. Do you have advice for developers who are now navigating this whole AI landscape, who are building their app for the agents or app using the agents or just, you know, entering the AI domain? What would you tell them like they should focus on what matters the most nowadays? I think in my case, it's interesting because I'm both a developer and a founder and I have like

many different hats that I have to wear every single day. And for the past two years, I've been ignoring AI to a certain extent. Like I knew the power, I was a user, power user, but I was never building with AI because we didn't have time. We had to like build the company, right?

So I had to just one day stop and be like, "Okay, let me look into this thing." And I think it's around changing your tool set in a way. Like, okay, I'm used to VS Code. I have to switch to Cursor, even for a little bit. Even if it hurts in the beginning, like I remember my extensions were not ready and I was like, "I hate this Cursor thing. It broke my whole workflow."

Now I can't live without it. Same with Raycast and the AI on the desktop level, you know, and same with so many other tools. So I think it starts from there. Just looking at your tool chain and thinking, how can I add AI enabled apps, uh,

And then the second part is just like trying to figure out the use case. Yeah. So I remember a conversation I had with the Stripe team and they were building the MCP server. And I asked them, like, how are you approaching it? Like the Stripe API is so big. There's so many endpoints. Does the Stripe MCP server give agent access to...

To their accounts. Wow, that's very powerful. You can create invoices, payment links. And with Stripe, there's a lot of different... If you want to create an invoice, you need a customer object. You need a subscription object. So there's a lot of chaining that you have to do. And I remember them telling me, don't start via the API. Just...

grabbing your open API spec and generating an MCP server. No, start from the use case. What are people actually doing with your product? And then you build like, you don't need full coverage of your API, just the most important things.

I think about that as a traditional software engineer that's been doing this for the past 15 years, now trying to convert to an AI engineer in a way. I have to be building with those tools and I have to start from the use case. So what is something I can optimize or make my life a little bit easier? Like the app you built for yourself, that's fascinating. It's a real pain or you're really curious about something.

And that's always the best when you're really curious about something. I guess that led me to the other question, which I love asking founders. I know you probably don't have time to work on side projects, but if you did have time, what are the side projects you wanted to work on? Wow. I actually do have a lot of side projects. I love that. I have a theme called Dracula that I build and I,

I just like solving problems that I'm facing every day. So with that theme was like, you know what? I hated the fact that I had a theme on my code editor and a different theme on my browser and a different theme elsewhere. I wanted to reduce, you know, my cognitive load when I move from different tools. So let me just build one that works everywhere. The same for Resend, which was just solving my own pain. So yeah, today...

I just have a lot of different pains. For example, I don't like dealing with personal life things like going to the DMV and renewing my, you know, like car registration or whatever or dealing with insurance. I would love to automate all of those things. I can't wait for someone to build an agent for DMV. That would be amazing. I will be a customer like day one if you're watching this. Please build it. Let us know.

But the Dracula theme is so cool. I remember when I first met you, I couldn't believe you were the person who made the Dracula theme. Like when you open up the item to like color theme and that's like one of the top themes you can add to.

I know it probably will take the entire episode to talk about the theme too, because it has an incredible story. But like, do you want to briefly talk about like how the theme came to be? And yeah. Yeah, it's an insane story. Yeah, Dracula has now 9 million users. And it's a side project, right? Recent is my main project. This is only a side project.

And it started because I was traveling. I was in Germany. I was in Germany and I was traveling to Spain and I got sick in the plane. I was like feeling so sick. I was like, oh my gosh, what's happening? I was alone. I've never been to Spain before. So I'm like, okay, I was feeling so much pain to the point that I had to call the flight attendant. I was like, hey, I need help. So they landed in Madrid. They took me out of the plane in an ambulance and

And I was like, okay, this is bad, right? They take me to the hospital and they're starting to give me like some medicine. I'm feeling great. I'm like, okay, I'm ready to leave this place. Thank you for the help, you know, but I'm ready to go to the hotel or something. And they're like, no, you're not leaving. You got to stay. Turns out I stayed there for three weeks. It was like that bad. But in the first few days, like I was already feeling a little bit better. So

I asked my co-workers in Madrid, I was like, hey, can you bring me my computer? Because it got stuck like in the airplane or something like, you know, like I just left in an ambulance. So my whole luggage was there. So they bring my computer and I'm like coding in the hospital. I'm like super happy. I have my computer there.

And then one day I leave the room just to get some water. And then someone comes in and steals my computer. No, in the hospital. In the hospital. So I came to my room. I was like, what's going on? Maybe they really want your program too. Exactly.

No, it was so bad. I felt it was like the worst day. And then, you know, the next day I called my coworkers again. I tell them what happened. And they're like, don't worry about it. We're bringing you a new computer. So they bring me a new computer. And as a developer, you do that thing with a new machine. You're like start to configure all your hotkeys and shortcuts and themes and

So that's what Dracula came about. I just wanted a theme that worked everywhere. So I built the first version in the hospital and then it just took off after that. Were there already other themes when you built Dracula? What's the most popular theme before Dracula? There was Monokai. There was another one that's like creamy color. I forgot the name now. Why did you name the theme Dracula? I don't know. I completely blanked on that. I don't know.

I was like, is it related to Germany? I don't remember if Dracula was... I think just because it was a dark theme, but it really helped me on my entrepreneurial journey because at some point I built a pro version and then I sold like $300,000 with a theme. It's just like six colors. So...

I would never imagine that you could sell collars online, you know, and people would buy. But that gave me the confidence then be like, you know what, let me build my own company. If this works, maybe something else will. I love that because there are people who are selling email templates too. Yes. Yeah. And now what you're building is basically empowering a new type of audience to be able to build their own Dracula, not for coming online, but for emails. Yes.

And they can go sell it if it turns out to be very good looking and people want to adopt it because emails are hard to implement. If it converts. Have you seen actually users of a recent selling like React email templates? Not yet, but there's a lot of libraries that are being built around that. Yeah, that's amazing. Okay, so I guess last question. If you have a crystal ball and you can predict the future,

What do you think the future of email and future of AI will look like? I believe today there's a lot of actions that we take as humans. And that's the majority of the work. When you go to all these different apps, you go to Superbase, the most databases you see there were built by humans. You go to Resend,

The emails were sent by humans or drafted by humans and then sent programmatically. I think we're going to see a big shift in terms of who is the actor, who is the creator. And I believe it's going to be the majority of the actions will be taken by agents instead of humans. And that's just the reality we're going to live in. So we have to rethink the way we're building product to support that reality.

Do you want to add more on how to rethink how to build product? Yeah. Because it's such a great point. Yeah. And to rethink these products, you really have to, you know, go down the whole journey of the user. It starts from the onboarding. You cannot have 10 steps or you cannot wait two days to get access to your account. You cannot, you know, wait for the account manager to schedule a call with you or to book a demo.

From that point, you need to experience the aha moment as soon as possible and the agents should be able to take action as soon as possible. And you have to rethink role-based access control. You have to rethink permissioning and authentication for these agents.

So every single layer of the product, you have to rethink. Even the way you store the activities, you know, like every SaaS has this activity space where they can record everything you did as a human. Yeah.

Like actually recording what every agent is doing is more important than ever, because if they screw up, which they will in the beginning, then you need to know what happened. If they take a destructive action, you need to know. So there's just a lot that will change in terms of how we build products. And we have to take that in consideration because humans are not going to be the only user anymore. That's powerful and amazing. Well, thank you so much for coming. This is a lot of fun. Yeah, thank you.

And that's all for this episode. I told you it was fun and I don't think I misled you. If you enjoyed, please do remember to rate, review, and share this podcast with your friends and colleagues. And keep listening for more great discussions about the nexus of AI, programming, and more.