Launch HN: Resend (YC W23) – Email API for developers using React (resend.com)
Why? When you look at all the biggest competitors like Sendgrid, Mailgun, Postmark, and SparkPost, you'll notice that they were all founded around 2009/2010, and they all have been acquired by now. Because of that, it's common to see them only prioritizing enterprise requirements and optimizing for sales-led growth.
Nobody is building an exceptional developer experience. Nobody is trying to innovate. There isn't a single developer-first email platform in the market today. We want to change that.
Email sending is the kind of thing that you should integrate and forget, but instead, you have…
- Templates that are hard to build: Typically, you can only send emails using HTML or plain text. Although we support both, we're introducing a new way of developing and sending your emails. With Resend, you can code your email using React instead of outdated <table> layouts thanks to our open source project (https://react.email).
- Slow performance: Current solutions only offer a single region for email sending, even when all your end users are located in another part of the world. We allow you to choose what region your emails should be sent from (US, Europe, or LATAM), which minimizes latency and improves time-to-inbox.
- Poor observability: Most tools keep you in the dark without knowing what really happened after you sent an email. Resend exposes all the events associated with your email via webhooks.
- Designed for marketers only: Existing solutions are too generic and built exclusively for product marketers and product managers. We're building a platform with a clean REST API and SDKs for Node.js, Python, Ruby, Elixir, Go, and Java. We also have examples of how to send emails using Vercel Edge Functions, Cloudflare Workers, Supabase Edge Functions, and other serverless solutions.
What's our backstory? When I was a CPO at Liferay, I faced the problem of sending emails at scale. We had enterprise customers complaining about deliverability, and I've been frustrated with existing services ever since. More recently, as a VP of Developer Experience at WorkOS, I once again had to deal with emails landing in the spam folder. After looking at all the different solutions out there, I've been obsessed with the idea of solving this problem once and for all.
We need to stop developing emails like it's 2010 and rethink how email can be done in 2023 and beyond. We believe that email development needs a revamp. A renovation. Modernized for the way we build apps today. That's why we're building Resend.
What issues have you had with email sending? I would love to hear your ideas, experiences, and feedback on any and all of the above.
276 comments
[ 3.3 ms ] story [ 341 ms ] threadBeing able to create email templates in React is great, too.
The very best of luck to you Zeno, and the rest of the Resend team.
Best of luck Zeno, keep it up
There isn’t much innovation happening since email is stable. I don’t want to design my emails in React, but I am probably not the target group since I am still running my own mail servers.
Edit: What I meant by "email is stable" is basically the way email is being sent and not email itself and the experience around it.
The web is also pretty stable, but when you look at the past 10-15 years, there's been so much evolution around it.
Doing things like rounded borders or dark mode is still very difficult, especially when you take into consideration all the different email clients like Gmail, Outlook, Yahoo Mail, Superhuman, and HEY.
The web evolved, and now we don't hear too many complaints about having to design your website to look the same across all browsers as before. Unfortunately with email, this is still an open problem.
Emails are still sent, received, and rendered similarly to the way they were 5-10 years ago.
There are probably more Show HN launches involving email than any other product category.
As far as being YC funded, well, that’s the purpose of HN isn’t it? I’m not personally convinced that you can’t maintain a good product after you getting acquired. I haven’t used these services enough to say, but maybe they fit into the market of their time, and has then failed to innovate or keep “great” in the decades that followed? If you ask our IT operations they will tell you that SendGrid is great.
Or the slightly longer version of how HubSpot is sort of our CRM system but also a front end for our on-prem Sharepoint and our Microsoft CRM and a couple of other things. It can send some emails, but not all emails, and when it does send emails someone wants them tracked not just by HubSpot but also by SendGrid because that’s how we track mails in parts of the business. Why do we have both HubSpot and Microsoft CRM you ask, well you are, one department really likes one of them and another department really likes the other.
I loath building email templates. It brings me back to the old days of terrible HTML tables.
We’ve found deliverability to correlate directly with the price of the service we’re using.
The cheaper the company offers access to a sending IP, the lower the quality of people using it, since price is the number 1 factor for spammers (a necessity since untargeted cold email spam has low conversion rates).
We use it and don't plan on switching for a few reasons, but I would not recommend it to most folks.
For example, I maintain a popular email sending library (Nodemailer) and if I could get a penny any time some user files an issue with something that is clearly basic for anyone who has ever even touched email, I would be quite wealthy. All these people are good match for a service like Resend, they just want to send mail for a reasonable price and do not care the slightest of what is going on under the hood.
I find it hard to believe there are a ton of this persona calling shots on what email service to be paying for..
Cloudflare via MailChannels is virtually free: https://blog.cloudflare.com/sending-email-from-workers-with-...
It lacks tooling / observability that a marketer would want though.
https://developers.cloudflare.com/pages/platform/functions/p...
Once we go for an email provider here, Resend will definitely be the first option.
Instead of hand-crafting an HTML template with <title> <p> <a> <h1> <img> <div> etc I'm supposed to use your custom React components (<Button> <Image> <Hr> <Link> ...) which you will promptly compile down to the tags I mentioned above. So...what value am I getting out of React at all?
[0] https://github.com/vadimdemedes/ink
Most front-end teams are using React nowadays. What happens when you adopt another email service is that they want you to learn the template language that they use - Handlebars, Mustache, etc.
Instead of having to learn how to do things with that language, your front-end team can re-use everything they already know from React land. Imagine being able to import the same button you have on your web app into your email template.
Not only that, but you can also use stuff like Tailwind to help with the styling of your email.
Personally, I was expecting the api to optionally accept a React Template, along with the Data, where upon the Resend api would Render it (or fail) then Send it. Passing a 'preview' param would return the rendered HTML/Text (for testing) - just a thought.
[1] https://resend.com/docs/api-reference/emails/send-email
Said differently - how many devs out there are screaming "I really need to send transactional email via React", when most apps are sending it via Python, Ruby, PHP, Java, and (back-end) JS.
But I think the targeting here is for a certain generation of companies where there is a very distinct backend/frontend split OR companies where everyone is a JavaScript dev (and the backend is Node). The backend folks send the email content and the frontend folks are responsible for building the presentation-layer stuff. The thinking here, I believe, is that those frontend guys do all their other work in React, so when they're given these transactional emails to build, they'd prefer to keep working in React. I think?
I agree that sending an email from React doesn’t make a lot of sense, but that’s not the target at which this is aiming.
https://mjml.io/
This makes sense, but ya aren't there serious scaling implications to this?
In such a system, sending an email is traditionally a pain (well, email is always a pain, but even more so when you don't have a dedicated backend). Being able to fan that out to an API call (plus a template system already in your frontend's language) just means it's easier.
The API part handles the transactional email and deliverability and all that. The React part helps with the handcrafting of emails using a familiar layout composition language (React). But that part is entirely optional; it's a separate open-source project anyway and you can use the API without React at all if you so choose (or conversely, use the React email templates without Resend).
That part of the logic wouldn't be in the browser (unless you're purposefully trying to emulate SMTP on the client for some reason). In Resend, for example, a 200 just acknowledges that their API successfully received your request and will attempt delivery soon. It doesn't necessarily mean the email was either sent from their SMTP servers or received by the recipient's server client. You can check delivery status later on in the dashboard: https://resend.com/docs/dashboard/emails/introduction#unders...
(And then optionally receive that as a webhook later on, if you want to notify the user of success: https://resend.com/docs/dashboard/webhooks/event-types#email...)
----
Edit: In case it wasn't clear, the value of something like Resend or (SES or SendGrid or whatever) is that you don't HAVE to write logic to handle the tricky parts of email delivery. You just send an API call to someone else's transactional email service and let them worry about all that.
Bigger companies with dedicated staff/teams might want to inhouse a lot of that stuff, but there are a lot of smaller companies (or non tech companies) that still need to do transactional emails but don't necessarily want to maintain it in-house.
In a resource-constrained team/org, it's the difference between a full-stack dev who has to split time between making the website and maintaining the backend(s) and infra, vs a cheaper frontend Javascript dev who can focus solely on the frontend UX/marketing/branding/etc.. The latter can matter more for direct-to-consumer companies who don't necessarily care about the backend as long as it works and isn't too expensive... those 3rd party services are usually much cheaper than hiring even a junior dev/sysadmin.
No, I'm very familiar with transactional email services and why its superior to SMTP.
> You just send an API call to someone else's transactional email service and let them worry about all that.
100%. But you also need code to do that. Typically the front-end form calls a backend endpoint (a controller for example in MVC) and then the back-end manages the request with the external API. Hence why there are endless docs like this: https://docs.sendgrid.com/for-developers/sending-email/quick...
At scale, those calls are actually handled by a message queue (like Redis). If you let the front-end code handle it, you would likely get throttled by the transactional email service provider.
That does sound like something better dealt with on the backend at sufficient scale. The Resend API rate limit appears to be 10/sec.
Your web-site is more clear in that it shows a Node.js snippet (and other environments, although funnily not just in the browser?). Then the site goes on to talk about the React components.
Perhaps "Email API for Developers, with React components" would resolve the issue. The title as it stands suggests I wouldn't be interested in this at all since I'm not using React. But actually, as an e-mail API, I would be (e.g. with a Hugo site).
It's likely to be brittle and also very slow - slow enough to almost cause an incident when we tried to use it in production because emails were taking _seconds_ to render.
I have to imagine there are existing tools for all this..
I reckon if you become another integration in Vercel, and maybe a option to install your open source react.email is presented when installing Next, that could go a long way.
I almost drunk the React everywhere coolaid (and have some NextJS projects) but not sure it is for me for various reasons (personal preferences), but plenty of people love that way of developing.
Another thing, thinking of living the future. You mention deliverability. Nothing more deliverable than avoiding email all together. (You are not an email company). Will Gen Alpha use email much? That's all I'll say - something to think about.
As mostly backend dev with some slight frontend skills I don't get the selling point of this.
Anyway, maybe I am getting too old?
There are a lot of reasons to have abstractions over HTML/CSS in emails, for all but the trivial cases. It is notoriously difficult to get right, since there are some features lacking and standards in the email client space moves way slower than browser.
A regular marketing HTML email would look unrecognizable to a lot of old timers.
For a major brand, CSS and pretty design is a requirement for all branded emails.
For that having a React wrapper that makes the hard parts easy makes total sense.
On a side-note though, emails really need an update. No, they don't have to support JS, but at least modern CSS options. Adjusting layout with tables and CSS float just doesn't seem right nowadays. I basically always use an email builder, just because desiging a good email is so tiresome. Using React can help make it easier, but some work has to be done by the email clients to get more up to speed with modern Web standards.
You forgot a whole lot of <table>, all the inline CSS and all the IE11 comment hacks. Oh, and also OfficeHTML or whatever abomination that is called, because Microsoft Word 2003 also remains alive inside Outlook.
Most people doing anything of medium complexity is already using some abstraction layer, such as MJML [1]. Also remember you gotta either test on multiple clients, or use something like Litmus.
HTML emails are no fun.
[1] https://mjml.io/
Citation needed.
I’m an admin for the largest email community online (emailgeeks) and when folks talk about code, everyone is talking about writing this stuff by hand.
This sounds like a pretty amazing art form if people are building cross-client compatible, rich, modern email designs with tables and inline styling.
https://www.youtube.com/watch?v=l7i7YDPcAcM
There are modern alternatives to manual coding both for developers (embeddable editors for SAAS) such as beefree, unlayer, chamaileon, stripo and for email designers like beefree, stensul, knak, stripo, taxiforemail...
Once that’s done it does drastically improve the speed of email creation though.
In my experience the more shiny the email is, the more logos and whatever components are around the actual content the less clicks I get. So i try to be just a branded level above a text email.
HTML is not designed to work over email and is not capable of describing an email thread, a conversation. Aside from that HTML over email is ridiculously trivial. Super trivial. It isn't the HTML that is challenging but the CSS over email that is challenging. It takes some practice to figure out, but if you are even remotely competent you DO NOT need table insanity. Tables are for tabular data only.
These are screenshots of actual emails I created back in 2006 for a company that no longer exists. It's a bit easier now than it was back then.
https://prettydiff.com/email/
However even with that you still gotta test on multiple clients.
If you want to use something like border-radius, for example, it won't work on some versions of Outlook, for example [1]. You either show a slightly different layout or you use workarounds. There are plenty of other examples like that.
I personally just use very simple emails, so it's <p> and <h1> etc. But other people have to work around those limitations, and not everyone is a developer with design knowledge that can tweak the design to a point where it is both simple and good looking.
[1] https://www.caniemail.com/search/?s=radius
As much as it pains me to say so, they're probably right. If they don't know how to make a static site, and they're familiar with something like Next, then they probably can go faster and just let the framework take care of building the assets.
I wish people still made static sites using boring tech but times have moved on, but honestly there isn't much difference in complexity between a NextJS static site and a Hugo or an 11ty static site.
Edit: And OP mentioned he suggested Hugo or some other solution which is miles behind tools in JS/TS world. Not to mention it is Python based and this team knew React
All it takes is to actually write the html that goes into a component, rather than the component. I don't see how any react dev wouldn't be able to do this.
Also, I, too, would rather use react. I'd rather be able to reuse components I already have or to make some to reuse later, and to keep the project organized in that way, plus future-proofing the project to a certain degree.
It also leans into a lot of email code best practices. Clear inputs and outputs and unidirectional data flow with React props, building reusable and composable components that work in all email clients without having to hand-rewrite table tags, and an easy way to inject test data or build out email templates before you have real data.
I've used react-email on one project now, and would happily re-use it in a future project where a team is amenable to having some TypeScript in their backend.
My one complaint / feature request is that it'd be really nice to have a way to basically "export" react-email into low or no dependency functions, since effectively all it's doing at the end of the day is providing you a function where you pass it an object, and it returns a string.
Seems like a better technology would be Astro.build. Basically same syntax as react but it’s really designed around static HTML generation only.
Really nice to see all the examples too.
Pretty wild that in comparison, "Twilio Sendgrid" doesn't even have a single code snippet on their homepage, and once a Rubyist clicks "Least more" and scrolls they're greeted with this: `sg.client.mail._('send').post(request_body: mail.to_json)`
Thanks!
Should I be able to send emails under one domain? - Yes, you can add as many domains as you want in case you wanna send from multiple domains
Do you support react-native? - Resend is designed to be used in the backend, so you'll have to call an API from react-native
Can I send it from the backend (eg next.js server-side backend)? - Yes, here's a Next.js example: https://resend.com/docs/send-with-nextjs
Is it for only transactional emails? - It's designed around transactional emails, but you can use it for other use cases
So does this mean that Resend won't get acquired? What is your exit strategy other than an acquisition?
Resend would need to expand beyond their main TAM when they get email right.
I'm wishing them the best.
I remember MailChimp not taking any funding for over 20 years and being completely bootstrapped, innovating and useful until they eventually got acquired and not shutdown.
Also the same for Postmark.
Both are profitable and were bootstrapped for years.
Sometimes it all ends the same way, the question is how long for Resend. Since they've taken funding as it is highly likely they are heading for an exit in under 10 years.
In comes...Company Y who can rapidly innovate for a few years until inevitably they also get acquired, then comes Company Z who has the same logic for starting as Company Y and on it goes.
This isn't necessarily a bad pattern for either the founders (they get an exit) or the consumers (they get a brief period of innovation). Give it a couple of years and I imagine we'll be getting Resend's successor.
As for Resend themselves, I think they're absolutely right - the email APIs today for non-enterprise businesses are ugly and opaque and if they can solve this, all the best to them and if I prefer them to current providers I'd be happy to be a customer.
Deliverability is the #1 problem all developers actually face with this imo. We have perpetual issues with extremely high importance, but extremely low volume transactional email from admin panels alerting various (usually non technical) people to things. For example; an important extremely high value custom order has been requested and requires senior signoff in a platform. As far as I can tell nothing really suits this, it's too low volume (<1k emails a month - maybe even a few emails a month) for it to work well with dedicated IPs and shared IPs constantly get spam blocked on the major MSPs.
In the the end we tend to use SMS or slack/teams webhooks for this.
https://learn.microsoft.com/en-us/azure/communication-servic...
• $0.00025 x 1,000,000 = $250 for sending emails
• $0.00012 x 10 KB x 1,000,000 = $1.2 for transferring data
• Total cost = $251.2
What am I missing?
Your thoughts on this would be most welcome.
Generating Boilerplate Projects
Rapid Testing (Think CIs)
Manage Environments and API Keys in Resend
Listing Domains and Email Sending Health
A way to 'Watch' email events in realtime for debugging.
Do you log the Email body ? If yes, I will give it a shot.
[0] https://postmarkapp.com/ [1] https://postmarkapp.com/email-analytics
Don’t store content - Requirements
7 days - $5 per month 28 days - $5 per month 45 days (Default) - Free 90 days - $5 per month 180 days - $8 per month 365 days - $12 per month
Are you stating you want the email body indefinitely though? Does Mandrill store this? I'm yet to fully check them out.
I see your docs mention a composer package in the PHP section.
[0]: https://github.com/resendlabs/resend-php [1]: https://github.com/resendlabs/resend-laravel
But what if I'm just a regular developer who doesn't use react? /s
Resend innovates at simplicity, no crappy dashboard, clean API design.
Thanks you.
I ask because it takes a long time to build up trust reputation among the major email providers to help ensure deliverability.
We run an exclusive transactional email service, meaning customers go through an approval process before they can send live emails. Transactional emails by definition are sent as a reaction to a users' action and _should_ therefore have a low spam-rate and fast time-to-open. If you can ensure that your customers are good email citizens and actually send only transactional emails, you don't even need to upsell dedicated IPs to your customers, as the deliverability of a high-quality, shared IP pool is better than that of an isolated IP address.
Email is in my bio, if you have other questions.
What's this service called? A link also works. Imagine many people in this thread are looking for alternative transactional email services...
https://github.com/siguelaola/mjmgr
It would let you write emails in mjml and react, and upload, manage and version them on Sendgrid. I had planned to make it a flexible system with support for other providers etc.
If someone wants to maintain or build on it, let me know.
Isn’t this what DMARC is for? I have this setup (along with SPF) with my domain with a strict “reject” policy and a dedicated inbox to receive delivery reports.
I do like that you are tracking whether the recipient opened the email or not. But most email clients are no longer loading images (including the “tracking pixel”) by default so this nice feature/metric can be misleading.
> More recently, as a VP of Developer Experience at WorkOS, I once again had to deal with emails landing in the spam folder
This usually means DMARC is configured incorrectly or just too many of your recipients are marking the emails as spam.
Besides the ability to write templates using react syntax, I don’t see why developers would use yet another centralized service in production.
DMARC alignment is trivial to set up, so even spammers can do that. That, amongst other reasons, is why all major spam filters are based on content, not DMARC alignment. This is why you can have 100% DMARC alignment and still end up in spam.
Failing to meet DMARC alignment will result in your email being marked as suspicious (with a big fat warning), or flat-out rejected (not delivered), but it typically won't be marked as spam (unless content is flagged as spam, of course). What exactly happens on DMARC unalignment somewhat depends on your DMARC policy, but mostly on the policies/implementation of the receiving provider. Each provider handles DMARC unalignment different.
One thing that is consistent, is that none of the email providers will reflect in any way if your email is flagged as spam or not. Otherwise spammers could trivially figure out which content trigger spam filters, and which content won't. A DMARC report will not tell you if your email is flagged as spam or not. This is also why most email providers will always fetch and cache tracking pixels, again to not expose to a potential spammer if their content made it into an inbox or not. This behavior makes it look like every receiver has opened the email, even though it never happened. This makes tracking pixels useless.
So, Resend's claim to show you 'all the events' means they can display how many mails were send, how many have bounced (due to various reasons, except spam), and how many tracking pixels were loaded. But as explained, the number of pixels loaded does not, in any reliable way, reflect the number of emails actually making it to the recipient's inbox.
Reliably sending email is an insanely hard, you can never guarantee delivery with email anyway. If the 'React' email template editor is the novelty in Resend, I'd suggest them using something like SES to actually send the email. Don't try this yourself, until you verified your product-market-fit and have the scale to invest (heavily) in your own delivery network.