Show HN: I built Mailhub – A scalable API for sending emails with ease not tears
mailhub.sh
mailhub.sh
First thought, UI looks great. Better than I've dealt with. However, this awesome UI information needs API desperately. While you are working on this API, please make a reporting API key only.
Pricing isn't ideal. I get wanting simpler pricing and initial X per month with Y Limit is great starter but being able to buy in utilization as an option after that point is better.
Premium having no daily limit will bite you. Telling you now, someone will sign up with stolen credit card, spam like hell and you will be left with clean up. Been there, done that.
Lack of SMTP Client support means it's nonstarter for us. While most of our apps use SendGrid API to send email, we have some SMTP legacy lying around.
to field in your API being string or string[] is frustrating. I'm sure it helps with onboarding, but I've found weakly typed fields always bite in the end.
You got a misspelling in Premium: "For all needs, all teams & all *projets*"
I understand your comment regarding billing, and we will work on that to make it easier to understand.
Regarding the daily limit, Mailhub is a v2 product of a previous one called Mailwind, which was a similar "plugin." We decided to rebuild everything from scratch—the code, branding, everything. So, we've already encountered scammers as you described and have implemented an effective system to prevent that:
Maximum security on our payment provider (Stripe Radar) A custom AI that analyzes sent emails (by code or template) and reviews the content. In case of excessive fraudulent sending, the account can be blocked. Thank you for the warning; we've already dealt with this kind of problem. I understand your request concerning SMTP. We aren't ready for this service yet, but we will work on it very soon. Do you have a contact I could use to alert you when this service is implemented?
As for the "to" field, you’re right, it could be an issue. We prioritized ease of integration but will ensure this feature is monitored closely.
Regarding the typo, fix in progress, thank you!
As for contacting me, not really, I enjoy my anonymity of Hacker News and anyways, we are satisfied-ish with SendGrid right now. So even if you got the feature, we are not potential customer at this time. I'll keep your company in mind in case that changes with SendGrid or I change companies.
EDIT: When I say Ops person in charge of email, email isn't my sole focus, in fact it rarely comes up. However, when SendGrid misbehaves, I'm first one that is called.
Thanks again for your valuable feedback; it’s definitely one of the most relevant, even though all feedback is important!
You seem to be a great asset to your team, so it's no surprise they call on you, haha. Best of luck moving forward, and thank you!
Referring to proprietary logic (fuzzy or not) as AI?
That is a nonstarter for some companies. Not saying it’s the wrong choice, but it will narrow your market.
> Telling you now, someone will sign up with stolen credit card, spam like hell and you will be left with clean up. Been there, done that.
Ignoring this advice killed some companies in this space.
It says:
Up to 500 emails / month 100 tests emails/month | 50 emails/day 100 test emails/day 50 emails/day
That's a bunch of conflicting info. I'm not sure what the actual limits are.
It also says "Remove watermark" in the free tier, but "No watermark" in the paid tier... what's the difference between those? Seems like you can have no watermark in either tier?
Finally, do you use dedicated IP addresses for sending? If so, how do you keep your IP reputation clean? What if a spammer signs up and sends thousands of spam emails - will my email sends also be affected because we share the same IP?
As for the watermark, it’s only present in the free plan.
At the moment, we’re simply using Amazon SES services and have implemented a robust system to monitor complaint rates, bounces, and especially potential spam.
We plan to use our own IPs to ensure better service, but our primary goal right now is to find our Product-Market Fit (PMF). It’s in the pipeline.
We’ve done a lot of work to prevent spammers. In the past, with the predecessor of Mailhub, we experienced this kind of problem and have put everything in place to ensure it doesn’t happen again.
As a project manager in several small startups, I've often been frustrated with the existing solutions.
In certain projects, I had to juggle 5-10 templates in multiple languages, and it quickly became a nightmare to manage on a daily basis.
So, I took all the points that drove me crazy and tried to turn them into something cool (or at least less of a headache).
Except for Resend, I find that most of them are overly complex, and in the end, we're limited. The developer experience is far from perfect, and I'm convinced there's a niche to explore.
And I'll say it again, but it's probably a bit of madness.
100 tests emails/month | 50 emails/day
100 test emails/day
50 emails/day
What are the limits really and what is the difference between a test email and a non-test email?
The pricing might not be the clearest. My apologies.
We haven't yet developed the option to rent IP addresses, but we could consider it in the future.
We'll keep our users informed about upcoming updates!
Thank you for your feedback.
I'm Clément, a freelance developer for 5 years now. I've worked in several startups and often encountered the same problem: creating stunning transactional emails was a real headache to create and maintain.
So, I created Mailhub, an email API with all the tools to make it easier to build, test, send, track & monitor transactional emails
Among other features, you can:
- Use reusable layouts & pages powered by Tailwind - Dark-mode & responsive supported - Access a virtual outbox - i18n - Build from pre-built templates ...
All of this comes with a simple API & reliable deliverability rates.
I hope you like it as much as I do. I'm really open to feedback!
See you soon
Only 2 real questions in my mind, both of which can only truly be answered over time: 1) price stability and 2) deliverability rates.
Rant: SMTP is just a bad legacy joke that should be augmented (replacement is probably not realistic) with some new API standard.
Indeed, your two questions will answer themselves over time, but we are doing everything possible to keep competitive prices. As for the deliverability rate, we have implemented several mechanisms to ensure that it remains optimal.
I agree with you about SMTP. Emails in general are a legacy joke.
Problem is, most replacements I've seen are even worse vendor lock in. While I hate SMTP to, it being one of last open two-way long-term communication systems out there is something most of us should be thrilled with.
There is no reason that sending an email can't be done with a simple, single API call. The back and forth "dance" that SMTP requires is just an absurd waste of time. There may have been a good reason for it at some point but today, it's hard to imagine what that was.
This could be a show stopper for a lot of applications.
Tailwind though… ugh… is proper CSS still an option?
(The expressiveness of the template language is pretty cool but uncomfortably similar to ColdFusion.)
otherwise it's really nice!
Yes, I had needs for my startup clients and never found a solution, so I decided to create one. I tried to combine the best of both worlds: flexibility by keeping HTML code and simplicity with Tailwind and other tools.
Thanks again for your feedback. I'd be happy to hear more if you try the product.
About the landing page, I took note of that, and I'll address it as soon as possible!
I can also use it with my own templates, where I pass your API the full email body as HTML? I've already done the work for managing my own email templates and would only need a swap-in replacement for the email deliverability part if Mailgun becomes too expensive or their service declines after their acquisition.
It looks like the only tracking is open rate? Now I don't enjoy being tracked myself, but sadly it's a fact of life in email marketing, and table stakes for email products – is there any click through rate tracking? How do you handle custom click through domains? How do you handle anti-tracking technology in Safari? How do you handle open rate tracking with Gmail and other clients pre-loading images?
A common request from marketing (name may vary) at my previous company was for all emails to be sent at a specified time. Do you handle this? If not what's your send-rate per customer, how long should customers budget for a campaign to go out? What's the quota per customer on the send API, how many requests per second can they make?
A common request from engineering at my previous company was for emails to be spread over a time range so that the site didn't receive a million hits at once, even just hits loading dynamic images from the emails, let alone actual click-throughs. Do you have any controls for spreading delivery over time?
How do you ensure your users are GDPR compliant? The example email on the homepage doesn't show an unsubscribe link, but these are legally required in many countries. How does the tooling support this? Do you offer end-users one-click unsubscriptions? Are users prompted when they attempt to save a template without an unsubscribe link to prevent human error?
Having developed a few HTML emails in my time, this does look like a joy to use for that purpose, but having seen a company try out different transactional and marketing email service providers, overhaul their email approach for deliverability, cope with the Safari tracking changes, keep a site online during sale periods, meet regulatory compliance both for the company and for our clients, and accidentally DDoS itself with emails multiple times in different ways, I'm not sure Mailhub solves or aids any of these problems.
In the end we mostly either outsourced the HTML email authoring for little money or used frameworks like MJML, and the HTML email "tears" went away.
If you have solutions to these problems, great! I'd highly encourage you to add them to your marketing page or docs (I couldn't see them) because these are things potential customers may be looking for. If you don't have solutions I'd encourage considering them.
I’ll try to respond to each point as thoroughly as possible.
Mailhub is a tool primarily intended for technical teams to use for transactional emails, although it's indeed possible to send any content you want.
There is tracking for both opens and clicks. Technically, it's similar to what the competition offers. I admit that we haven't yet tackled more specific issues like Safari's anti-tracking technologies.
We’re currently working with simple technologies. We’re still in the early stages.
We don’t have a campaign scheduling feature, as we’re focused on transactional emails, which are typically sent via the system in response to user actions. That’s why we haven't implemented the suite of tools you mentioned.
As for GDPR compliance, it's up to the developers themselves to ensure they comply. We have several ideas to make this easier, and it’s in the pipeline.
Regarding MJML, I completely share your view and am not trying to challenge that technology. I'm simply offering a similar tool (which simplifies email editing) but from a different perspective.
We’ve taken note of all your very pertinent remarks. Thank you for these valuable insights; they’ll help us determine the future of Mailhub.
Thanks!
I am on firefox on Linux.