Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Mike Perham's Sidekiq was what I modeled my own business, EmailEngine, after. I took my decade's worth of expertise in email protocol implementations (I also run the open-source Nodemailer library) and built an email gateway app my customers can download and run on their machines or servers. Just like Sidekiq Pro, the customers need an active subscription to run it, but the app runs on their premises, and they maintain it. I only run the key generation and validation server, which costs me around $50 per month, including all the backups and so on.

I quit my job to go full in with EmailEngine exactly one year ago, when MRR for EmailEngine was $500, now it is $3,900 and steadily growing. I do work full time on it, but the result is async - the work I put into EmailEngine today brings me income sometime later, and the recurring income I receive today is unrelated to any effort I put into the company right now.



Congratulations, that’s great. I’m always happy to hear of more successful indie developers.


Thank you for your inspiration!


Unsolicited feedback, always link to your business in your posts.

I googled “emailengine” and it’s wasn’t super obvious which was your business since so much paid ads exist for that search.


Oh, yeah, I forgot my pitch. The link is https://emailengine.app - EmailEngine acts as a mail client, basically the same way Thunderbird runs on desktop, or the iPhone Mail on the phone, but instead of a GUI it has REST API and instead of desktop notifications it sends JSON webhooks. And instead of a single email account, it can manage thousands of accounts.


How does it compare to eg Nylas? I was looking into that for an email app I wanted to make, but they were enterprise only it seems. I also found your business but I didn't want to self host just to try it out.


I've written an overview about the differences between Nylas and EmailEngine here: https://docs.emailengine.app/emailengine-vs-nylas/

TL;DR Nylas is hosted service that does way more than just emails. Also, it syncs all emails on monitored accounts to their DB, so when you make an API request, it hits their DB. EmailEngine is self-hosted and runs directly against the mail servers, so when you run an API request, the request ends up in the mail server. Both approaches have their pros and cons. Other than that, there aren't any other good solutions than building everything yourself by using any IMAP library.


I appreciate the answer. I believe Nylas also has a self hostable option, just to let you, as when I was doing my research they mentioned that many secure industries like finance or healthcare wouldn't allow storage of emails on Nylas' database, so they allow self hosting. Of course, that is probably much more expensive than yours. Thanks for your last sentence as well, it clears up a bit more about the business, I asked in another thread but was just curious what types of customers need to integrate with email providers, as I'm making an email client so it's core functionality, but I assume most other industries simply use APIs from Gmail or whatever, rather than raw IMAP these days.

Edit, looks like you've answered in the other thread, thanks.


You have a bullet point about compliance / hosting concerns. I'm curious, do you have any idea how many of your customers care about that?

Do you have any concern that a customer is going to look under the covers and re-implement your product? I would guess the overwhelming majority of customers are going to be happy to just consume the API and go about their own business, but some products attract copycats, and handing out code / build artifacts makes that easier.

The tradeoff you've made makes a ton of sense if you're not concerned about copycats.


Compliance issues are a real concern. For example, I have some customers who switched from Nylas to EmailEngine because Nylas closed their Canada DC, even though EmailEngine is an inferior product. I'm not really worried about copycats, as it's a niche and complex project. There are literally hundreds of email RFCs, some as long as a book, and you would need to have at least an overview of these. You can already use IMAP client libraries in any language, but what EmailEngine does is cover all the weird edge cases, like handling sequence numbers as identifiers. Those who have the skill likely have better things to do, and those who don't probably find easier things to copy.


Who are your main customer segments? I ask because I'm implementing Microsoft, Google and Apple email support for my app and Microsoft and Google have an API now, while Apple is still a pain. Beyond that, for custom email providers, I'm not sure who else is major enough to implement for. I guess I'm asking, couldn't your customer do something like I'm doing, to cover 80% of the use cases by using the Microsoft and Google APIs and spending some time using an IMAP client for Apple iCloud, and discarding the other smaller percentage of other email providers?

Granted, it still does kind of suck to implement even these three, but I'm sure it would likely suck less if I were part of a bigger enterprise who could afford Nylas for example, which I looked into but seemed too enterprisey for my needs.


Most EmailEngine customers are smaller SaaS services like niche CRM providers etc. EmailEngine can also work with Gmail and MS365, as they support IMAP in addition to their proprietary APIs. So you get quite a large coverage by using EmailEngine out of the box (all smaller providers + most Gmail/MS365 accounts). Additionally, in some cases going with IMAP is the only way - for Gmail email API access, you need a very expensive security assessment that you might also fail for various reasons, like when your use case is not allowed by Google's terms. In comparison, there are no conditions for using app-password-based IMAP for Gmail. EmailEngine does not work with email accounts where their organization has disabled IMAP/SMTP access entirely (common with on-prem Exchange servers, a lot of MS365 accounts, etc.)


Makes sense, I saw the security assessment stuff for Gmail which I suppose I'll have to contend with as well, haha. I'll take another look into EmailEngine then. How do you charge, per connected user (and how much, generally)? Is it a monthly usage based subscription if so?

Edit, I just took a look at your FAQ and saw the price was 695 Euros a month. It is strange to not put this pricing on a prominent pricing tab I believe, rather than making me click a link in the FAQ to figure it out. Any reason why it's set up like that?


My main customer base is smaller SaaS services (less than 10 people), and this is the price that works for them or what they would expect - if they compare the costs of building in-house vs buying EmailEngine. Very small companies (single-person ones) and very large ones (one of my customers is a major bank in Europe) are exceptions that I do not target directly, but if they decide to become paying customers, then I don't object and gladly take their money.


The price is fine, I'm more so talking about not having a pricing section on the main website and instead being on another website domain.


Well, yeah, there is no good reason tbh, I kind of haven’t just thought about this


Thanks. Yeah it would help future customers looking for pricing as that's the expected paradigm on landing pages these days, to have a dedicated pricing page or section.


There's a fixed yearly subscription fee https://postalsys.com/plans

There are no limits on how many EmailEngine instances you can run or how many email accounts you connect. So, I don't differentiate between customers at all. I have single-person startups and large enterprises paying the exact same amount. Maybe not be the wisest option potential-revenue-wise, but this approach has worked well for me so far.


If you're worried about copying the code, I could see having the self hosted artifact be compiled or otherwise obfuscated would probably deter most people who wanted to reverse engineer it, since it would take significantly more time and effort to open up a compiled app than something just made in JS for example.

If you're worried about copying the API design, well, the implementation is the hard part, not necessarily the API design, which the Google vs Oracle lawsuit also showed, interestingly enough.


EmailEngine has all the code public [1], even though it is not open-source but is source-available. Some core parts I even published under the MIT license, like the IMAP client library I built from scratch to serve the special requirements EmailEngine has for IMAP access [2]

My thinking has always been that those who try to hack the license validation stuff and replace the missing build pipeline were never going to be my customers in the first place, so every second I would spend on them is a wasted effort.

[1] https://github.com/postalsys/emailengine [2] https://imapflow.com/


I was just about to post emailengine here, the business model is so similar to sidekiq.

Any other great ideas?


Yeah, it is so similar because I blatantly copied it. I had the old Changelog podcast episode with Mike Perham pretty much on repeat when I tried to figure out how exatly to set up my business.




Consider applying for YC's Fall 2025 batch! Applications are open till Aug 4

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

Search: