Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Resend (YC W23) – Email API for developers using React (resend.com)
432 points by zenorocha on June 13, 2023 | hide | past | favorite | 270 comments
Hi HN! I'm Zeno, founder of Resend (https://resend.com). We're building a modern email sending platform focused on providing the best developer experience.

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.




Help me understand the React selling point. Existing email sending software supports text and HTML because that's what email is. No email client out there supports JavaScript, virtual DOMs, event loops, SSR or any such fancy web technology.

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?


Sure!

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.


I think the confusion is coming from the framing of "Email API for Developers Using React" as the title for this post. React has nothing to do with "an email API" as far as I can see.

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).


Thank you, that's a lot more clear. I was going to click through to find out how they protect the mail server secrets when sending emails from the react based client.


FWIW the Tailwind implementation in react-email is not well done. The code double render React to static markup just to parse it into DOM then parse out the style and className attributes using a lot of regex https://github.com/resendlabs/react-email/blob/main/packages....

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.


So weird, not sure what all the requirements are. I might just call "getComputedStyles" on the DOM elements and use that to generate inline styles for all the elements.

I have to imagine there are existing tools for all this..


The emails are generated server-side, so there is no native DOM here to work with. There probably are existing tools for this, so yeah it's odd they're running with basically proof-of-concept quality code here.


Ya, but why does a transactional email service have anything to do with the front-end....I feel like I'm missing something very obvious but I can't seem to figure it out...


I don't mean this snarkily, but have you ever used a transactional email service? Literally all of them support frontend, I'd much rather use something like React than "Handlebars" (which Sendgrid requires https://docs.sendgrid.com/ui/sending-email/how-to-send-an-em...)


I think he may have wondered how would, say a Python backend using Resend Python SDK, render a React Email template and send it. Their API docs [1] for "Send Email" has an option for specifying a 'react' component to render the message but it's only available on the NodeJS SDK. Otherwise you pass HTML and/or Text.

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


Exactly this.

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.


Preface: I'm with you on this.

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 think you’re conflating terms (or possibly concepts) here. This isn’t about sending emails via React; this is about sending HTML emails generated from React components via a backend. The examples shown on the landing page are of Node.js, Next.js route handlers and Remix loader functions, the latter two being fancy abstractions over Lambda functions (or isolates).

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.


Er, you can send the emails via whatever backend service you want. React merely acts as a templating language and when compiled down to HTML, you can then send the resultant file with Python, NodeJS, etc.


I've used pretty much all of them and in most cases you're sending the request via some message queue (front-end -> async to back-end -> message queue -> async returns to back-end DB), which is managed on the backend. I'm scratching my head as to why relying on the browsers threading to do seems like it offers any advantages...


But the code populating and sending the email is rarely (ever?) Front end code


Sure, but presumably you want your emails to generally match the aesthetic of the rest of your product, which is easier if you can use the same tooling to make them as you do the frontend of your product.


React doesn't do its own styling though, and since email will not run js, you are basically talking about css at this point


Maybe that is the secret sauce of this service. They render the email with react and automagically convert that to something that works for email?


I think they literally just use React as a templating language, basically. You write React components and this service renders them down to email-friend HTML. Like SSR but for email.


I've worked at a couple companies (medium-scale) with home grown email solutions. The server-side rendered templating grew into being used for HTML email as well. It helped the backend devs as the tech that rendered the webpages also rendered the emails (all server side rendering), and the frontend devs needed less training to go from just frontend to frontend + emails. It was sort of a path of least resistance thing and it did have its drawbacks.


> It was sort of a path of least resistance thing and it did have its drawbacks.

This makes sense, but ya aren't there serious scaling implications to this?


Not really? The system worked as designed for the years I was there and sent _many_ emails. Rendering a template was never so taxing as to not scale. From a workflow perspective, each email was a template file, so if you had a ton of emails it was easy to parallelize the work across frontend devs


Simpler websites often don't need a backend anymore (beyond automated, managed hosting). Many of them can just e a frontend package that can be deployed anywhere as static output files (CDN, any file host, Vercel, Netlify, Cloudflare Workers, S3, etc.)

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).


This makes sense, but what if you're using a message queue to send transactional emails? Why would you put that logic on the browser?


Not quite sure I follow. Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later?

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.


> Do you mean your frontend sends a "send message X to user Y" request to your backend, which then enqueues it internally and handles the actual SMTP later?

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.


Ah, I see what you're saying now! Sorry I misunderstood, and thanks for explaining.

That does sound like something better dealt with on the backend at sufficient scale. The Resend API rate limit appears to be 10/sec.


How can you send an email from the front-end without the next scammer using your keys to do the same?


I _think_ the idea is just to use React as a templating language to write HTML emails, rather than dealing with the quirks of email HTML directly; it's not about sending emails from the frontend.


But why use React to do that when you can achieve the same thing on the backend?

https://mjml.io/


The selling point is that this allows leveraging existing React knowledge, as per the founder's comment upthread.


There's also react-mjml, a React wrapper around it. Works great, altho it's easy to mix up React props with mjml props. Just requires devs to actually read the documentation


Unfortunately, the react-mjml library is no longer maintained: https://github.com/wix-incubator/mjml-react#notice-this-proj...


The business wants to maintain the same consistent style with all communications to the customer. A lot of thought goes into design systems, they don't want to throw that away in their emails.


Emails are rendered like websites with a reduced featureset.


This isn't really true. More like static pages targeting a million different rendering engines with unbalanced feature support


I think the people that will love this are NextJS/Vercel people, who have decided React is for them for 1. Frontend, 2. Backend, 3. Build Time, and now want to add 4. Emails, and might want to reuse that <Layout> component they carefully crafted for emails too.

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.


I know mustache, handlebars and many other scripting languages. I never used react and have no idea what tailwind is.

As mostly backend dev with some slight frontend skills I don't get the selling point of this.


"Instead of hand-crafting an HTML template with <title> <p> <a> <h1> <img> <div> etc"

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/


> Most people doing anything of medium complexity is already using some abstraction layer, such as MJML

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.


Manual coding is getting very inefficient since it takes hours plus it requires a lot of testing (ie with litmus or emailonacid).

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...


To be fair I am using a very limited 'style' for all my emails and usually they just work. Everywhere

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.


A lot of those template systems you just mentioned require an email dev to create brand appropriate modules.

Once that’s done it does drastically improve the speed of email creation though.


This seems wild to me. Can you share examples of the complexity of the emails people are coding 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.


Check out this talk from Mark Robbins from 2018, he's been leading the industry with interactive email for a long time now.

https://www.youtube.com/watch?v=l7i7YDPcAcM


I don't think this supports your point of "everyone" talking about doing this by hand. If anything this guy is an outlier.


My point is backed up by what I can see posted every day in a community of 18,000 email marketers.


Yes, normally I'm a little adverse to abstractions over HTML, but HTML for email is so convoluted and non-standard that I think in this domain it makes a ton of sense. There may be a world of devs specialized in HTML that works in Outlook (bless you folks) but for this dev used to targeting the browser something like mjml is a lifesaver.


Please stop the insanity.

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/


When you have absolute freedom to design the emails around the limitations, sure, that works and is certainly much better than the soup of tables and IE11/Office stuff.

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


HTML for emails is notoriously difficult to get right. To be decent, HTML emails require arcane CSS rules, inline CSS, table layouts, etc., and testing in many different clients (because they all have their own quirks). Fixing something in for a client without breaking it for another client is not straight-forward either. Email solutions have worked around this via premade components—as a template, in React, or even as a UI with drag and drop.


I was in a meeting a while back where a team that was tasked with standing up a few dozen completely static websites was discussing what React components to use. I asked why they were using any front-end JS framework at all and not just creating static html sites, maybe using a generator like Hugo or Eleventy if they wanted to templatize. The answer was that they didn't know how to create plain html sites without JS. That was moderately shocking to me. I offered to work with them to create the static html solution and they declined, saying they could be more productive with React.


they declined, saying they could be more productive with React

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.


you can make a static site with NextJS too

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


Oh, I'm sure they're right, but it was wild to me, someone who starts any new web-based project with a static html page.


If you are building static sites, all you are doing with reactjs is abstracting parts via components, right?

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.


Because I want to write JS(X) instead of having to suffer through learning yet another templating DSL. I don't understand why this si so hard for people to understand, templating languages suck.


Maybe, but spaghetti jsx really sucks too.


This isn't an argument. Spaghetti templates are even worse


Sure, if you write everything in one file, but that's why componentization exists in React.


It sadly no longer shocks me, I've seen many "front-end" engineers rely on React as a sort of crutch for building UIs. Even for non-interactive UI. :(


You get the comfort of using react components instead of fighting with HTML tables to make your emails look nice. I think it's awesome! It's analog to what ink[0] does with CLI outputs. Sure, you could write fancy CLI outputs in bash, but ink takes the pain out of it and makes it easy.

[0] https://github.com/vadimdemedes/ink


It's also like react-pdf, where they give you react components to easily build out a PDF document without getting into the nitty gritty of the PDF spec. I'm a fan of this paradigm


That's a great analogy, big fan of Vadim's ink project btw.


Having worked on a number of product email systems where you have an existing codebase, while not exactly intuitive this is basically exactly what I've wanted. You can easily code share environment-agnostic code with your frontend (Things like user-facing text formatting, localization, handling of commonly shaped API objects like users, generating links to specific pages.)

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.


It's what every software developer out there using mindlessly. They are just putting React components and mixing them. NextJS also helps shield them from the back-end. You'd be surprised how many of them cannot differentiate between the back-end and the front-end and which parts are being executed by the server (it's netlify!).

Anyway, maybe I am getting too old?


I don't think it's just us getting old. Newcomers to the filed don't really understand HTML and CSS. It's just "React components" to them, and they aren't looking deeper than that.


I'm getting the feeling that a lot of old timers also don't understand HTML and CSS in emails, from the responses I'm seeing here.

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.


That's pretty unfair. It doesn't look like an html page they'd create for the web but I'm pretty sure they'd recognize html and css. Would someone who templated it in react see the connection?


As long as you stick to only HTML that was available in the year 2000, and use zero CSS, your mails will come out the same in pretty much every client.


Absolutely, but show what this will look like to the marketing team and they will, probably rightly, tell you that times have changed.

For a major brand, CSS and pretty design is a requirement for all branded emails.


You can do all of that without CSS though. It’s just harder.

For that having a React wrapper that makes the hard parts easy makes total sense.


How would you make branded emails without CSS?


I see it more as a way to provide better Developer/User Experience over existing mailing services. It seems to be the main selling point of the entire platform. Given that it's price-competitive with other services, it might be enough to attract users looking for new solutions and possibly even convert those already using other services.

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.


React is a really good template language and allows you to stay consistent with branding across multiple products with minimal investment


Exactly. High consistency + low investment, that's the perfect combo


Agreed react doesn’t make sense for email. But the syntax can be better than classic templating languages.

Seems like a better technology would be Astro.build. Basically same syntax as react but it’s really designed around static HTML generation only.


Watch your free tier very closely. An unfortunate part of being in the email business is that spammers and phishers are always looking for free ways to send their emails on ips with a good reputation. It quickly becomes a game of cat and mouse which detracts from the business, so make sure you have a effective strategy to prevent misuse when allowing customizable emails with a generous free tier.


Thanks a lot for the advice here. That's definitely an area where we spend a lot of time and one of the reasons why we've been under a private beta for the last six months.


This point does need strongly reinforcing - that you have a free tier at all creates conditions for sharing an outbound prefix with low-reputation senders. It’s a definite barrier to adoption, and one you can only lower with an engineering-based explanation of your mitigations.


Your competitors have been acquired but you are funded by YC… so there is a high chance this will happen to you as well.

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.


That's a valid point.

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.


The web is not stable at all. Everything about it except TCP/IP change rapidly.

Emails are still sent, received, and rendered similarly to the way they were 5-10 years ago.


Having worked with a few of them, currently with SendGrid I think the market is ripe for disruption. It’s a terrible, terrible, experience to work with these systems when you need e-mail visibility to play into a larger setup. We’re doing simple stuff, like giving our sales personal an information stream to track that links into their HubSpot and a few other systems, and it’s frankly so bad that one of our developers wrote as much of the business logic as was possible outside of SendGrid. I’m sure it works well for the IT services part of our operations, but for development and automation purposes when you need to put some gaffatape on all those 300 systems that your business bought. Then it’s not very good.

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.


Out of curiosity, if you are spending a lot of effort to track the data in HubSpot, why not try to send emails directly in HubSpot?


Because that would make sense.

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.


Thanks for the insightful reply! :D


> There isn’t much innovation happening since email is stable

There are probably more Show HN launches involving email than any other product category.


I disagree. Those companies were all made long after email was stable, but having used SendGrid I can say it's definitely not the best DX, and it is indeed tailored to marketing.


I absolutely want to design my emails in React.

I loath building email templates. It brings me back to the old days of terrible HTML tables.


That looks promising, I'm currently looking at Sendgrid and Mailgun.

2 points I would bring :

- You need a cheaper plan. Mailgun have their flex plan that's 0$ for 1000 emails per month, and then 1$ for any extra 1000. It would cost more to send 50k emails, but I'm not there yet, I need a cheap starter plan with a lot less emails. My total infra cost is going to be around 30$, so I'm not going to drop an extra 66% to send maybe 1000 emails per month.

- If I reach my plan limits, you need to still deliver my emails and I' ll happily pay for them. Your FAQ says : If you exceed your plan limits, you will be notified and given the option to upgrade to a higher plan. If you don’t upgrade and repeatedly exceed your plan, your account may be temporarily deactivated.

My platform relies on emails to register users, MFA backup and transactions invoices. So if my email provider doesn't send my emails, my platform is broken. Yes, I could "just" keep an eye on my usage, look at it multiple times per day. I could also take some of my time to put some monitoring in place to wake me up at 3AM if there's a spike in traffic and I need to upgrade my plan.

Or, I can do none of that and register to a Mailgun Flex plan, or a 20$ Sendgrid plan, and not spend my time babysitting my email provider. Both Mailgun and Sendgrid allow going over plan quota and just charge you a premium. Don't not deliver emails, you're an email provider, that's disruptive.


Do not use Mailgun. Their support is extraordinarily poor if you use it for something mission critical. We've had our grandfathered in account downgraded twice now resulting in outages, and their support took _days_ to respond.

They were bought out by Private Equity a while ago so it looks like they are in the stage where the company's value is being extracted.


> They were bought out by Private Equity a while ago so it looks like they are in the stage where the company's value is being extracted.

Same is probably going to happen to this.


FYI, the site is returning a 500 error currently.

Anyway, re: the substance of your post--I've used a few email services for the handful of small web apps I develop. I'm currently on Postmark and I really like it. You state "Nobody is building an exceptional developer experience" and "There isn't a single developer-first email platform in the market today", and I have to disagree. Postmark has great developer experience. And the specific points you raise aren't much of a rebuttal:

- Templates: your own react.email project already has a Postmark integration. More generally, templating solutions don't need to be tied to the email service. I prefer to use separate libraries for rendering and then pass off the html output to the email service anyway.

- Slow performance: Postmark has excellent delivery speed.[1]

- Poor observability: Postmark (and every other service I've used) provides events.[2]

- Designed for marketers only: Postmark is clearly designed for developers, as are several other services.

I am rooting for you! But I'd also like to say that before you trash talk competitors, please be sure you have substance to back it up, because some of us actually like those competitors :).

[1] https://postmarkapp.com/email-delivery

[2] https://postmarkapp.com/email-analytics


I’m also a happy Postmark customer and also bristled a bit when I read the allegation that they don’t have a good developer experience. Their developer experience is pretty good, actually.

BUT their JS library has been a shitshow for years now. Like, it works. But the readme links to outdated documentation and 404s. And in the library documentation you can get into an infinite loop of “click here for more info” taking you to back to the page you’re on.

It’s still usable. I can just find the page I need with a bit of googling, and actually I stopped using the JS library and just interact with their API directly with HTTP these days. But it’s definitely a sign that they’re not paying attention to that side of the business and developer experience anymore.

Which is, like, fine. Postmark is a great product. It does what it needs to and it does it well. But it’s fair to say they’re not hungry anymore and haven’t been for a while. And although I don’t totally understand Resend’s value prop, the market’s definitely big enough to support someone new and hungry so good luck to them.

PS: Zeno, I saw in a sibling comment that you guys had a upstream outage during your Launch HN. Damn, such bad timing haha!! At least it’s back up now :)


I've been also a customer of Postmark for years and I am delighted with the experience. I feel a bit attacked when reading the original post as well.


There’s an outage with our upstream provider (AWS Lambda): https://health.aws.amazon.com/health/status

This issue is only affecting the Marketing Website and Dashboard.

The Email API is up and running normally.

More updates here: https://resend-status.com


The Marketing Website and Dashboard are back to normal now.


We have built out some of the things you said were missing for our email system at SmartSurvey. The biggest annoyance is random blacklisting from email providers. Mimecast almost always greylists us, which is annoying because it creates an artificial baclog on our mail servers, others work fine and then all of a sudden they block you - sometimes you can contact them, sometimes you can't.

We also have a big problem with automated tools like mimecast or Office365 because customers don't receive emails that were blocked by some rule or heuristic or other but they just contact us because they can't see what their receiving system has done. Even when we show them the logs.

Our sysem sends out about 50 different types of email and some are easy to handle when they bounce, others are not so easy so it will be interesting to see whether your use of webhooks will make things that much better than e.g. MailJet (who we use for some emails) since all of email failures arrive via webhook.

Other problem is to do with IP ranges of the sending servers. Using SES probably mitigates some of that (I assume most providers whitelist SES) but if you ever wanted to move to your own hosts, without a /16 subnet, you can easily get blacklisted (again for unknown reasons) and without enough servers to move to, your deliverability suffers.

I think the one thing that would help us if we were using a third-party system would be failure messages with specific links to solutions that could be displayed to the end user. e.g. MimeCast 5.7.2 could link to an article about giving permissions to access a Mimecast mailing list. That would save a lot of explaining since we would just show that message to the customer.


> 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.

So does this mean that Resend won't get acquired? What is your exit strategy other than an acquisition?


I think this misses the point: regardless of Resend's exit strategy, they are innovating now, unlike the competition (allegedly), and that's the value proposition.


...Until they have an exit, and they can only have this because they took funding, which is my point.

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.


"All the big players in the space got acquired or had a big IPO. Instead of supporting them choose our scrappy VC-backed startup so that one day we can get acquired or have a big IPO."


This is what I was thinking possibly an IPO.

Resend would need to expand beyond their main TAM when they get email right.

I'm wishing them the best.


I think this might be a future pattern for a certain group of startups. Company X creates something useful and then gets a acquired but because of natural bureaucracy of large companies Company X slows innovation.

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.


Yeah, Heroku is proof enough.


this is the most gorgeous dev tool design/website i have seen in a long time. and you JUST graduated from YC? amazing

my real question is - how do you ship so fast and well? what do you trade off to be able to do this?

for email - my main wish is that it be integrated well with an auth and analytics system. the emails i send out should be aware of what the user has done, and if you've given me your email i should already have created an account for you, etc. seems all like one and the same - have a total representation of the user.

i am guessing i'm far from the first to talk about this. so the smaller, second idea, is just a good/gorgeous "contact center" like experience with multiple channels and levels of email engagement that people can opt in/out of. so eg you can choose to get emails from me every day/week/month/quarter/year, or based on specific topics. one can of course build this with resend, but it wouldnt be GREAT. people/developers/startups need help making this usually overlooked experience GREAT.


Thanks for the kind words!

Shipping software, to me, is like a heartbeat.

You need to ship small improvements in a steady rhythm, but you also need the big spikes which represent the major releases. If you only ship minor things every week, people won't care. If you only ship one thing every year, people will forget. It's important to find a balance between both.

When it comes to quality, it's a matter of asking ourselves: "Are we proud of this?" There were two occasions when we discussed shipping this website sooner, but we decided to postpone it because it simply wasn't quite there yet. Sweating the details is more important than people think.


About your email wishlist - I agree entirely.

The more integrated it is with auth and analytics systems, the better and easier it will be to get started.

The whole unsubscribe flow is overlooked by most companies, and having a built-in drop solution for this would be awesome.


I think if you’re targeting developers, SES is your biggest competitor. Their very cheap pay as you go pricing is more attractive than your monthly pricing. If email templates with react is your usp, I think I’ve seen libraries that offer that already.


Resend seems to be a UI layer on top of SES, so it is probably not a competitor. People could use SES directly, but if the target group for Resend is a “modern front-end dev” then they probably do not want to, or do not know how to, and thus need that UI layer.

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.


> but if the target group for Resend is a “modern front-end dev” then they probably do not want to, or do not know how to, and thus need that UI layer.

I find it hard to believe there are a ton of this persona calling shots on what email service to be paying for..


> I think if you’re targeting developers, SES is your biggest competitor.

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.


Are there any unpublished limits for this? Asking for a friend :)


There are no unpublished limits. I'm the CEO. We don't specifically limit Cloudflare traffic.


How does this work if we don't need to validate domain?


We have a lot of anti-spam capabilities in the platform and if you abuse the service to send actual spam, your account may be rate limited or blocked. But if what you are sending is good email and we don't see signals to indicate it is abusive, then there aren't any limits on how much you can send.


This is quite cool than - will give that a try!


But SPF and DKIM, how do I configure that?


There’s a UI for it in Cloudflare once you have a domain. Seems to work pretty well - emails from my new domain go to directly into inboxes, no spam markers I’ve heard of.

https://developers.cloudflare.com/pages/platform/functions/p...


Watch this space.


SES has a terrible developer experience.

We use it and don't plan on switching for a few reasons, but I would not recommend it to most folks.


I think this is a fair criticism, however it's clear that there is a market for "polished, dev-x first, react focused cloud platforms". Just look at next.js and Remix, both of which solve problems which are already solved by combining normal cloud providers and open source libraries, but crucially with a lot more head-desking and glue code.


Does SES still have a reputation for being flagged as spam more often than other senders?


SES reputation is medium at best. But they allow everyone to send emails so you get what you pay for...


Which competitor has the best reputation for transactional mails?


Email is old and established, so basically you get what you pay for.

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).


Resend is, or at least at launch was, using SES as their email provider.


Sucks because SES reliability is a mixed bag and more competition would be good.


Is there something that's cheaper than SES and similar in reliability? Do Oracle, Google/ Microsoft Cloud offer something similar (pricing and endpoints)?


doesnt resend use SES themselves to send emails? domain dns settings in their dashboard appears to hint at this IIRC


Going against the cheapest in the market in a race to the bottom is a fool's errand


I tried Resend and Custom Email feature reveals SES. I think it good when Resend build on top of SES


I had the chance to get hands-on with Resend during the private beta and found the Resend dashboard DX features to be really helpful during the development process. HTTP logging, email filtering, and webhooks (also with logging).

Being 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.


Thanks leggetter, it means a lot coming from you.


You state that deliverability is the problem that has been your pain point for years & you want to solve it.

I have 1 question.

How?

'cos React email templates isn't the answer to that.


> 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.

I can't think of a single email platform I've used as an email marketer/crm marketer for a decade that didn't expose a full event stream for all emails.


SendGrid exposes it for like 14 days I believe. I tried like hell to get data from before that and support told me you're required to store that yourself. So not super helpful until you realize you needed it in the first place.


Postmark shows the body for 45 days by default, and it can be extended to up to a year. https://postmarkapp.com/email-analytics


This is very true, but I can understand why a transactional provider probably doesn't want to sit on masses of old data like that. Marketing ESP's all usually store the data indefinitely.


Sendgrid doesn't log sent email bodies, as a simple example. Think harder!


Their webhook doesn't send the full body? I'm sure you at least get the data if not the exact data sent...


I don't think any email provider sends the body via webhook. AWS SES certainly doesn't, which I think Resend is built on


Mailgun does


If SendGrid fails to send an email it won't tell you why or that you even attempted to send an email.


We are using Resend for our new products at GuruHotel (YC19) and the experience is really impressive. It has never been so easy to create email templates. The Resend dashboard is simple and clear, we love it.

Best of luck Zeno, keep it up


Thanks damianricobelli! We spent a lot of time making sure that dashboard was simple and clear, I'm glad you noticed it :)


Not for nothing... your site (resend.com) is a HUGE CPU hog. I didn't get a chance to view or read anything on the site because I quickly closed the tab after my CPU rocketed up.


Would you mind sharing what computer/OS/browser you're using so we can try to reproduce on our end?


Not 100% but it looks like using ~10% of single core on my macbook too (It's too much for a static landing page). Perhaps it's caused by the black Rubik's cube animation on canvas.


I'm using Firefox on Android on an S21 FE 5G and having the page as the active tab without any interaction seems to cause 30% CPU usage in my about:processes listing.


Just FYI, https://www.resend.com should have a 301 to https://resend.com


Totally, adding that 301 redirect now


this really ought to be a vercel default. idk why so many platforms (like netlify too) require/default to www subdomains. defeats the purpose of acquiring a short domain


Looks cool, i would agree the space needs a shakeup.

But I see you don't have an inbound offering, I'm looking for something similar to what sendgrid and mailgun offer in that i can receive a POST request to my API everytime someone sends an email to test@mydomain.com. Ideally with the following features:

1. Solid email MIME data parsing into JSON or XML

2. retry handling

3. included in the free tier (mailgun excludes this)

4. inbound routing based on parsed data


this too! and throw in OCR of any pdf/image that i send you and you really have a stew going


> 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.

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 is an anti-impersonation standard, not anti-spam.

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.


The changes to tracking pixel is a bit complex. Yes some email clients do not load any images. Other email clients load the image through a proxy to hide the user IP (google/yahoo). Apple's Mail Privacy Protection (MPP) loads all images at the time it was delivered to a device. That metric is still very useful because you know the device received it and it's an active email address. Versus the alternative is to send an email and wait for an click if they have images turned off.


> 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.

Why does this matter? Does the difference ever realistically exceed even one second?

(Assumptions: being transactional email, messages are generally small enough to play well with typical TCP window sizes; and you can send a message within about three round trips, which I could easily be wrong about—I suppose you’ve got TLS handshake, SMTP handshake, then data, not actually certain how much blocking happens in each of these steps. Maybe two seconds is a more realistic maximum realistic difference?)


Microsoft Azure offering

https://learn.microsoft.com/en-us/azure/communication-servic...


Are you currently using it? I would love to hear what you like most about it.


Assuming that each email is about 10 KB in size, sending 1,000,000 emails with Azure would cost:

• $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


> We need to stop developing emails like it's 2010 and rethink how email can be done in 2023 and beyond.

Do you have any awareness of how tacky this sounds?


Not sure if you are actually developing the emails or not, but from a front-end developer's perspective, I hate to touch my email templates codebase because it has to be coded in certain way that works with the email provider.

I cannot see what the end result is going to look like until I actually send out a test email and see it in my email clients. This DX indeed feels like 2010 if you compare it with today's DX for developing websites.


Yes, I am.

So this is like Litmus?


I have been looking for a basic Mailgun type transactional email service for my React based project, and I believe this is exactly what I need.

I asked Adam to think about designing some reusable transactional email templates for Tailwind UI a few months ago. It looks like Resend would pair right up with Tailwind perfectly :)

I added Resend to my R&D to do list, and I hope to partner up soon: https://github.com/elegantframework/elegant-cli

Congratulations on the launch, and keep up the great work!

I saw that Guillermo also to note of your work, so props on that too!


That's pretty cool! You should definitely try Resend if you're already using Next.js, React, and Tailwind.

This should be a good place to start: https://react.email/docs/components/tailwind


Hey Zeno, thanks for the resources! The Tailwind component looks perfect.

What's the best way to contact you and link up virtually?

I'd love to talk about Resend more, and show you what I'm cooking up. I really like what you are doing, and I think we share the same cohort of users :fistbump:


What i would really love to see in a developer email service is also some workflows baked into the emails. There's a ton of times you would want to wire up a service and just set it for transactional events but also as sequences and with a default set of templates wired up. Think Zapier meets Sendgrid for emails and a set of templates maybe wired for default dev flows like Signup, Verification, Billing receipts.

We do use SG for transactional emails and their email DX is frankly abysmal. Also not a big fan of html for transactional emails but sometimes you gotta do it.


That's great idea! Today we have some integrations (https://resend.com/docs/integrations) available, but it requires you to use a separate service.


This sounds a lot like ServiceNow to me


Which existing providers are you using on the backend for delivery? Mailgun, Sendgrid?

I ask because it takes a long time to build up trust reputation among the major email providers to help ensure deliverability.


Looks like they're using AWS SES. From personal experience, none of them (SES, Mailgun, Sengrid) are suited for critical, transactional emails. I'm working in the same space and we're running our own backend.


@ctas since you're running your own backend, how did you solve the reputation problem to ensure good deliverability? I would have thought that using a dedicated IP on an existing provider like Sendgrid would be the best solution for critical transactional email.


There's no one-size-fits-all-solution to ensuring good deliverability. Dedicated IPs are often (not always) a sign of weakness as they indicate that the shared IP pool lacks good reputation.

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.


> We run an exclusive transactional email service

What's this service called? A link also works. Imagine many people in this thread are looking for alternative transactional email services...


It's called Markix. There's currently no public website, because it's invite only, but if you're interested you can mail me at tas@markix.com.


I suspect most serious customers will want dedicated IPs, and then they can send using their own servers. Relying on shared IPs is always going to cause problems, especially for high volume users that can sustain enough traffic for their own clean IP sets.


I have to say I'm impressed at the breadth of their SDK support (even Elixir) and how idiomatic they seem at first glance in each language (though too bad there's no python types yet).

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)`


> What issues have you had with email sending?

Most email services assume that you are a big, US based company and care about following US anti spam laws, which require you to disclose your address in each email you send. As an Eu-based hobbyist running their services without registering an official business, I have no address that I can safely disclose and no willingness to deal with the legal system of a country that I have no interest in. What are your policies on this?


I have a couple of smaller personal projects that need transactional emails (mostly just notifications of things that have happened or weekly summaries, etc). Currently using Postmark but now they're going away from credits to monthly subscriptions. I don't send nearly enough emails to justify doing the monthly subscription, but I send more than the free tier allows (this is the case for most services). I'd probably be at the cusp of your free tier but I also have 3 domains. Currently I'm sending approximately 2k emails per month, if you had a hobby plan around $5/mo with unlimited domains and around 5k emails per month - I would sign up. Otherwise I'll probably just load up on Postmark credits and then eventually switch off to something else entirely down the road.


Just had a super negative experience with Postmark support after being a steady customer for years, and I can only attribute it to their recent acquisition by a marketing company. They put me on a mailing list trying to force subscription change, and when I complained bitterly about the content and frequency of these marketing messages, pushed back with tone policing and told me to unsubscribe or delete them, something I haven’t heard since the old-school spam houses of previous decades.

Adding injury to insult, the unsubscribe interface didn’t even work until I’d disabled a content blocker.

So they’re dead to me now. There’s definitely room in the market for developer-first high-deliverability transactional email.


Hi Zeno! To help you have some reach in Brazil, I just posted this on TabNews: https://www.tabnews.com.br/filipedeschamps/resend-nova-plata...


Ohh nice, thanks for the cross-posting there Filipe!


Filipe, that's really nice of you! Cheers!


I don't really see as most of these features being particularly new or different, there are loads of SDKs and packages around for rendering emails and sending them with various providers. It's really a non-issue.

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.


I have had good luck with MXRoute for this. They have a fairly strong antispam stance on their platform.


Oh, great shout. Thanks.


So I have used Sendgrid, Mandrill, SparkPost and SES in production and dabbled with Mailgun for side projects. The biggest issue I have is with Logs where other than Mandrill, no one shows the actual Body of the email in logs. For our purposes, we need that.

Do you log the Email body ? If yes, I will give it a shot.


Postmark[0] have that and store it for 45 days[1] which is really handy. I use them, not affiliated.

[0] https://postmarkapp.com/ [1] https://postmarkapp.com/email-analytics


They announced extended retention as well recently, up to a year.


Yes, 'paid' add-on.

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


$12/mo is not a meaningful sum of money if you care about this, at all.


Mailgun will store the email body for 3-7 days (depending on plan/settings). I'm definitely not an advocate of mailgun as a whole, but their logs are really good in my opinion.

Are you stating you want the email body indefinitely though? Does Mandrill store this? I'm yet to fully check them out.


Zeno! Since no one else has said it on this thread, thank you for your work on Dracula.


How do people actually use Sendgrid, Mailgund,... and any crappy email services outhere ? Day by day, i got upset and stressful working with "enterprisey offerings".

Resend innovates at simplicity, no crappy dashboard, clean API design.

Thanks you.


I am using MJML but custom components aren't great, happy to see this one. Also would be great if you take a look into adding email action buttons, calendar integration and other modern features.


Ohhh I love this suggestion. Great idea!


> they were all funded […] they all have been acquired by now […] nobody is trying to innovate

> rethink how email can be done in 2023 and beyond to innovation

1. Is your plan to follow your competitors path from innovation to acquisition to status quo and be the BestPlatform for the next 10 years, waiting for the next innovating startup to take over?

2. Or do you consider keep on innovating, following the JS or DX trend or whatever clever innovation? If so what’s your plan to keep on innovating after acquisition whereas others failed ?

Thanks for the post and good luck.


Setting up email sending for web apps can definitely be a pain. I have been using Google API for this but I dislike working with their libs because their documentation is confusing to me. Finally I often have no design guideline on emails. I assume this will let me utilize my existing codebase components to generate the html? Or is it more limited than that. Anyway will keep this one in mind for a couple of my projects, thank you


I'm truly excited about Resend and the innovative approach it brings to email sending. Zeno, your vision for a developer-first email platform is refreshing and much needed in the market.

I believe Resend has immense potential to disrupt the email sending space and become the go-to platform for developers and businesses alike.

Love the fantastic design! Congrats on the launch.


I dunno if this is interesting to anyone but a while back I built a mjml email manager.

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.


As soon as you support inbound email handling we'll definitely give it a go. Mailgun have some critical blockers (and potential security vulnerabilities) that have meant we're looking for an alternative to switch to ASAP.

Ideally by then you'll have migration guides from every big provider and so it will be even easier! Thanks for innovating in this space - it's much needed!


Roger that.

Adding support for inbound emails is definitely on our roadmap.

Great idea on the migration guides!


Love how half the whiners in this thread have clearly never had to send rich HTML emails that work in a variety of mail clients, but happily post their shitty hot takes.

Yes, what Resend is selling makes sense. If (especially after the additional explanation in this thread) you don't get it, it might be you.


For me, the biggest annoyance was not being able to Zapier in new entries into a drip campaign. I just refused to use providers I couldn’t zapier together. For the section of the market that is small time, I am not going to implement custom API integration. No zap, no deal.


Congrats on the launch but I can’t see why I would go to this over Postmark. It’s so easy to get up and running, templates are solid, they have Zapier integration and the monthly fee starts at free for 100 emails and then $15 a month for over 1,000 a month.

What am I missing?


Well for one you can send 1000 emails for free with resend instead of 100 with postmark.


It's actually 3,000 emails for free with Resend


Curious on your plans to integrate .NET/C# as a method for sending via Resend? Any plans and timeframes you can offer? Thx!


How long does it take to have my domain whitelisted? and should I be able to send emails under one domain? Do you support react-native? Can I send it from the backend (eg next.js server-side backend)? Is it for only transactional emails?

Thanks!


How long does it take to have my domain whitelisted? - It usually takes only a few minutes depending on the DNS propagation

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


thank you!


It's good to note that this product has an open-source version https://react.email/docs/introduction


Both founders come from an open source background, so having some sort of open source component was very important to us.


Small piece of feedback, but I clicked on the Get Started button expecting to see docs on how easy it would be to use your product but instead was directed to a login page, so didn't look any further.


could you please elaborate on what the actual realworld problems are with "slow performance", if my customer is in Germany, but the transmission of email happens from Newfoundland, Canada, is it really that terrible that it takes 100ms more to send the mail? do people notice?

a far far bigger impact is if mails arent transmitted immediately, but every 1, 5 or 10 minutes.

Am I missing something here, or is this just marketing for the sake of marketing?


Reading through the docs, some thoughts:

- RE Observability, the lack of APIs to tag emails and retrieve them by tags makes this worse from that perspective to me because I’ve used Mailgun’s APIs before to pull down all emails we’ve sent in a burst to allow reconciling it against external data. No way to export data programmatically means that I can’t really do that type of reconciliation.

- some weird things in the docs like in the NextJS example it provides both raw HTML and react bodies for the email; not sure what this means. Also not clear why you don’t use JSX to render the email templates which seems not that idiomatic.

- as mentioned in a separate comment, GDPR/SOC2 stance would be good to know.

But looks promising, been burned by incumbents just generally having bad support, so looking forward to variety here.


Congratulations Zeno! What an awesome launch, really excited for you and the team at Resend.

Once we go for an email provider here, Resend will definitely be the first option.


Thanks a lot lucasfcosta! Let me know when you start integrating, I would love to hear your feedback.


Zeno, is Resend planning to have a CLI (linked to my account), since your product is a developer first email platform.

Your thoughts on this would be most welcome.


Yeah, that would be great. Out of curiosity, what's your use case for sending emails via CLI?


For me it is the following:

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.


We use Resend for our transactional email at https://depot.dev after migrating away from Postmark following their acquisition. It's been awesome so far and because our app is Remix underneath the hood, it was delightfully easy to get our emails exactly how we wanted them.

The visibility into what emails have been sent, to who, and what the content was is also incredibly helpful when we are talking about transactional emails. Double bonus for being able to share that email as well.


I've been dealing with email deliverability for the past 4 days as part of a new project.

The requirements are to send login codes when the user provides the email for a likely small site (maybe 100 active users a month). Eventually maybe send 1 email per day per user for notification reminders or something. Everything is transactional, no marketing. (Are notifications marketing or transactional?)

I'm directly implementing the http call. Most services don't have that different of request JSON so it's pretty straightforward. I'm likely not going to use the API for anything else. A curl example will typical show everything I need to know.

The emails I want to send are basically SMS style messages. No HTML or other noise. I would prefer no body logging. I assume such short messages may be an issue for spam filters?

subject: login code body: login code: abcd

(I did have the login code in the subject too, but those show up in some console pages and I suppose are more likely to be logged)

SendGrid

I initial used SendGrid since we used it at my prior job. Generally fine when using gmail addresses, but every non-gmail mta was rejecting the emails due to the IP being in multiple blacklists. So as a new SendGrid account we were placed in a shared IP pool with blacklisted IPs.

A support request reply included a link to an April 6, 2023 blog post discussing their "shared IP address pool improvements" (https://sendgrid.com/blog/shared-ip-address-pool-improvement...). Since I won't be sending a lot of emails, don't want to track users, and users don't even have to open the email to see login codes it sounded like we would never get a better IP pool.

IDK if our usage would ever require more than the free tier max emails. However, to get out of shared IP pools, $80/mon ($960/yr, maybe theirs a deal but doesn't matter because it's a small site) is required. OK, but their support docs also say that it's up to the user to initial monitor the IP in spam blacklists, etc.

The entire thing I want to pay for is NOT having to deal with any of that and have my transactional emails delivered. Yes, some of that is on the user not spamming, but I would also be fine if they were scanning emails and notifying me of spammy behavior proactively.

So I moved on.

Postmark

Seemed promising. Said all the right things on the website. Created an account, verfied an email, got a server token, and started implementing. For unknown reasons, the use a custom header instead of standard oauth2 bearer authorization header. I could modify my code to send the custom header, but I don't like that idea. Additionally, it seems like a potential security issue as general proxies or other things that log http requests would like not log authorization headers, but would log unknown headers. Probably small.

Maybe unreasonable to abandon for such a "small" reason, but does this imply anything about their other design decisions? I didn't have a lot to lose so moved on.

Mailgun

This time checked the API first. Uses the http user for the token. Pass

smtp.com

Didn't seem like they had a free tier, seemed more oriented towards marketing. Didn't care for their website so moved on.

Amazon Simple Email Service

I don't use AWS. Terrible docs. I just need one endpoint to send an email. Not immediately obvious how to authenticate. Doesn't sound like it provides else but sending. Searches indicated maybe blacklist type problems, IDK.

SES doesn't have a standalone email company type of home page with a curl example or anything. It's just some service down in the bowels nobody cares about until it breaks. That's fine though.

MailerSend

Through Google I found MailerSend. Curl example on homepage. Signup was realitively easy except I messed up the domain verification. I'm using Google Domains with Google Workspace which creates its own SPF record. It's not immediately obvious that exists in Google Domains and then requires deleting the entire Google Workspace sythetic record. That's not MailerSend's fault though as they did have a useful error message that I didn't read.

They require filling out a form to approve everyone before sending email outside your domain. Seems like humans are actual doing the approval. My initial submission was denied, but resubmitting with more detailed info about company/site (more than 6 words) was approved.

MailerSend's domain verification success email went to my gmail spam. So that wasn't a good start.

The IP isn't in a blacklist and my test users that were having problems are at least receiving login codes now. At least 1 went to spam.

I can't say if MailerSend will turn out to be any good long term, but ok so far.

Conclusion

A recurring problem with all of these services is that my usage will likely only fall into the free tier with paid tiers being excessively expensive for a small site. If they aren't making money off me, they likely aren't going to care if I have problems. A $20/yr plan would probably be fine or up front buy a bunch of email sends or something.

It feels like any company that starts out targeting transactional only eventually is either bought by a marketing company or adds marketing emails. You certainly can't grow revenue off small sites using free tiers and likely can't if VC backed either.

Since it's a low volume of emails, it seems like as long as my server IP isn't already blacklisted and I setup SPF/DKIM I could probably send the SMTP directly and skip the middleman. Maybe when I get time.

Sorry that's so long. Maybe some of its useful. Did anyone actually read to the end?

EDIT: I don't care at all about email templates


That's definitely useful. Thanks for sharing the entire journey.

There's a lot to unpack here, so maybe it's better to chat directly. Let me know if you ever want to give Resend a chance.


What is the advantage over something like SES? It seems you need to do basically the exact same code for the same result.


I built something using react-mjml and storybook (storybook-server). It takes a bit of plumbing but the devx is very nice.


That's why we built react.email, you should check these examples: https://demo.react.email/preview/airbnb-review


Looks great Zeno! Does the "Dedicated IP" increase the volume I can send through a specific domain?


You mention that you have a Java SDK but I can’t find it on your website.

Can you please share a direct link to the Java SDK?


Not the OP. It’s not listed in the “quick start” section of the docs but their SDKs are available on GH. This is their Java SDK

https://github.com/resendlabs/resend-java


Please for the love of god do not decide for me where I want to be.

I signed up, confirmed my email, opened the app and was browsing through it and was on settings tab when I got a phone call. During that call I had to look up something so I opened a new tab. After the call I went back to resend's UI to watch it blink and all of the sudden I'm on the dashboard again.

So I tested it, I went to the settings page again, switch to a different tab and then back to Resend again just to watch it switch back.

There is absolutely ZERO reason for this functionality. It is not a better UX, it's an annoying UX you do not know what I am doing or where I want to be on your website.


Could you not find a million other ways to provide this feedback less abrasively? People like you unnecessarily exacerbate the stress of launching a new endeavor.


I'm sorry was I not asked to give feedback on a launch post? Did you not see this line:

> I would love to hear your ideas, experiences, and feedback on any and all of the above.


There's a difference between giving feedback and giving feedback with tact, no need to be so harsh even if you are right.


(deleted thx to dang)


Please don't bring in personal details (even public ones) from elsewhere as ammunition in an argument. I understand the impulse and I'm not saying the information is irrelevant. It's just not worth the cost/benefit of what it does to the threads. It only makes them meaner and more personal. Better to resist the temptation.

https://hn.algolia.com/?dateRange=all&page=0&prefix=false&so...


Wow, looks like almost all of their tweets/comments are exhausting.


Criticism phrasing is important. Just because someone asks for feedback doesn't mean they're OK with an abrasive tone. Bugs happen -- I'm sure they didn't intend for the experience to be that way


That's pretty bad, looks like some UI bug. We're investigating it right now.


> Email API for Developers Using React

But what if I'm just a regular developer who doesn't use react? /s


That's totally fine, you can still send emails using HTML or Plain Text.


This is awesome! I have a project that I need to send some emails on so this is perfect


Cool! Let me know if you need any help with the integration


How does the react email templating work in non javascript backends? For example Rails?


We render the React components on the server side.


Meaning your server?


They use (and are makers of) https://react.email which works on client side or server side, through NodeJS. So you could spin up a NodeJS server, send your React components through and compile to HTML, then use whatever email service you want, but I believe Resend does all of this natively via their servers. I personally use react.email with Sendgrid.


Congrats Zeno. Have tried today and falling in love with Resend. Currently installed it with my sites. Easy to setup and looks stable. Would you plan to announce another plan in the middle of Free and Pro? I think 20 monthly and 50k emails sometimes overusing. 10 monthly and 20k emails or something.


No mention of PHP SDK?

I see your docs mention a composer package in the PHP section.


We do have PHP [0] and Laravel SDKs [1]. It's mentioned on the homepage as well.

[0]: https://github.com/resendlabs/resend-php [1]: https://github.com/resendlabs/resend-laravel


Any thoughts on third party integration such as segment?


Definitely on the roadmap


Your homepage looks quite similar to modal.com


+1 for supporting Elixir from the starting line


How long have you been doing this startup for?


We officially started in January


Any plans to allow Svelte components as well?


Why limit it to 100 emails a day for the free plan? Makes the 3000 limit feel like a false advertisement unless you have 100 users signing up every day.


> false advertisement

No, very clear, quite literally right below

"

Up to 3,000 emails / mo

100 emails / day

"


I mean it makes the 3000 number meaningless if you are not sending 100 emails every day.


Is this for spamming?


Congrats on the launch! What’s your stance on GDPR and SOC2? I’m making a B2B SaaS and we need to vet our vendors, would be helpful to know. Thanks!


Just use Mailgun.


This is so cool. I am going to build a command line app around this. Love it! All the best!


Awesome! Can you show me when you're done? I'd love to see it :)


why would anyone downvote this ? ffs




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: