Why developers trust Resend, with Zeno Rocha
Resend founder Zeno Rocha explains how React Email created a coherent path into a paid email API, why crowded categories demand severe scope discipline, and how every detail either compounds or erodes a developer’s trust.
Zeno Rocha is the founder of Resend and React Email, and previously created open-source projects including Clipboard.js and the Dracula theme. Resend set out to build the Stripe or Vercel of transactional email.
Zeno breaks down the story behind the two-product strategy, the work of teaching and distributing open source, the quality bar required to challenge entrenched vendors and the small signals that tell developers a product was made for them.
The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.
Why start another email API?
My co-founder and I were frustrated by older providers, acquisitions and recurring deliverability problems. We built an experiment, then friends insisted on using the unfinished API in production and one accepted a Stripe payment link. That first payment showed real utility. The larger ambition was an email service with the speed, clarity and developer experience people associated with Stripe and Vercel.
How did React Email become part of the Resend strategy?
The journey begins before sending: a developer has to turn a Figma design into archaic, inconsistent email HTML, test it across clients and then add delivery and observability. React Email supplies free, unstyled components that render consistently across major inboxes. It works with any provider but leads naturally to the next job, where Resend’s paid API sends the result — similar to the relationship between Next.js and Vercel.
Why think about the story before finishing the product?
Coding the solution is not enough. Define the hero, the painful status quo and the sequence that makes the strategy coherent. React Email was a bet that engineers wanted their normal React workflow rather than a drag-and-drop editor. Releasing that open-source first chapter gave people an immediately useful tool and made the commercial second chapter understandable instead of introducing an unexplained email vendor.
What did Clipboard.js teach you about open-source distribution?
Only a few days of its two-week build went into library code; the rest went into the README and website. A concise explanation, familiar visual demo and carefully ordered learning path helped it stand beside launches from huge companies. Developers often spend nearly all their effort on implementation, but an excellent project also needs substantial work devoted to teaching people why it matters and how to begin.
Is there a repeatable formula for that kind of launch?
The durable advantage is repetition, not a timeless trick. Projects fail, a later one reaches ten people, and the difference teaches the next attempt. Expectations for documentation, examples and presentation also change. Consistently improving distribution, maintainability and brand over many projects matters more than copying the badge layout or mascot that happens to work today.
How does de-scoping help a company compete with incumbents?
Resend cannot match fifteen years of SendGrid features with a small team. It must make a narrow first version feel ten times better. Severe prioritization protects enough time to reach that quality before burn rate or schedule wins. Each “good enough” approval also teaches the team a lower standard, so preserving the bar requires saying no, deleting work and sometimes delaying a release until everyone is proud to share it.
How does the team raise quality without turning review into blame?
Work is collaborative and unfinished by default. Someone may open rough code, another engineer strengthens it, a designer improves the interaction and someone else edits the story. Instead of listing why a teammate’s draft is bad, demonstrate an improvement in the commit and invite critique in return. That works only when people share the desire to raise the industry’s bar rather than defend individual ownership.
Why is competing on features alone insufficient?
Developers choose products that reflect what they care about: speed, design, considered APIs and respect for their workflow. Matching every incumbent checkbox produces another incumbent-shaped product. Start with the non-negotiable hierarchy — delivery, security and data integrity — then make usability and craft visible. A detail such as keyboard-only waitlist entry can communicate “this was built by someone like you” without a positioning statement.
How do a founder’s brand and the company’s brand affect trust?
People buy from people. If Resend claims obsessive design while my own work looks careless, customers may assume the polish was hired for one page and will vanish inside the product. Consistency across the founder, website, documentation, API and support signals a durable value. Developer trust is difficult to earn and remarkably easy to lose when one surface contradicts the story.
What is developer experience in practical terms?
It is the sum of every detail. A clear homepage leads to relevant SDK examples, structured docs, a fast first API call and an MVP that works on a Sunday afternoon; each step increases confidence enough to recommend the tool on Monday. Errors, confusion and neglect compound in the opposite direction. The goal is not universal approval but a product distinct enough that the right developers genuinely care.
Links & references
This episode is brought to you by WorkOS.