Live data from Hacker News

Launch HN: Resend (YC W23) – Email API for developers using React

resend.com

181–190 of 277 posts

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#181
post #30

> 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 acquisiti…

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.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#182
post #66

Earlier quoted context omitted.

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 wou…

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?

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#183

Earlier quoted context omitted.

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.

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

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#184
post #45

Earlier quoted context omitted.

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

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.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

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

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#187
post #45

Earlier quoted context omitted.

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 up…

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.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#188
post #122

Earlier quoted context omitted.

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…

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

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#189

Earlier quoted context omitted.

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.

Re: Launch HN: Resend (YC W23) – Email API for developers using React

#190
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

Post reply on HN