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