First of all, let's take a step back.
Email is probably the first Internet applications. It was there before the Web. Its core component is the SMTP protocol that describes how messages are sent and how they are routed to the final recipient. It's the equivalent of the postal service: You just write the recipient's address on the envelope and the postal service takes care of how the envelope will be delivered. SMTP stands for Simple Mail Transportation Protocol.
In the first days of email, this was enough. The email landed on the server you had telnet access, and you could use a text client that opened your inbox (a text file with all your emails) and presented them to you.
Nowadays the emails arrive on a server, and we use POP3 or IMAP, two other protocols to read them. IMAP allows a mail desktop or mobile clients like Outlook, Mail.app (that runs on Macs) or even web clients like Roundcube to download the emails that have arrived on your mail server, organise them in mailboxes (that are usually presented as nested folders), flag them, mark them as read or unread and delete them.
This is all that is allowed by IMAP. (POP3 is even more limited and not widely used anymore.)
All web services that I know of support SMTP (of course, no SMTP = no email) and IMAP. SMPT+IMAP is the golden standard of email services and allows users to access their emails using the mail client of their preference.
But this also means that IMAP defines what you offer to your clients. You can't offer a mail client whose features contradict with IMAP, because you have the risk that if the same user used your client and then an IMAP client, the whole experience will be messed up. When Gmail launched IMAP support in 2007, we all realised that our labels (a novel Gmail feature back in the day) can not be mapped to folders. (Just google "gmail IMAP labels".)
Which brings us to HEY. HEY is often criticized for not offering IMAP support, but this is what allows it to be different and offer novel features. Here are some that come to my mind:
- merging conversations
- renaming conversations
- attaching notes to conversations
- "blacklisting/whitelisting" (screening) senders.
Almost all the features highlighted in https://hey.com/features/ can not be implemented in IMAP (or you have to use hacks, special folders, make sure that the contacts app the user uses is aware of screening, etc.). And this is what makes HEY different.
If I were part of their dev team, I would feel liberated:
"Here is a database containing the emails of a user, what can you do with it? Go crazy."
Different is not necessaryly better. Some users have built efficient and elaborate workflows using the existing offerings from Google, Microsoft and others.
But if you are not satisfied with how your mailbox looks like, if you've thought of declaring email bankruptcy, then HEY may be good for you.
Personally, I couldn't be happier. I've had my @gmail.com address for 15+ years and I still remember how excited I were when I got my Gmail invite (*), but for the last 10 years I hated opening my mailbox. HEY changed this.
Today, I purchased the annual subscription. However, I won't be sending emails from HEY (I use Gmail and BCC my HEY address) until they support custom domains: Next time I tell someone "my new email is...", it will be on my own domain.
PS: Someone commented on HN that "Paid email without IMAP is like renting a house and you're not given the keys."
That's not the case exactly. Typically, you have a "mbox" file on the server and your IMAP client uses IMAP to download the emails to your local "mbox" file. If you want to leave HEY (or if you just want to archive them), you can take your emails by downloading the mbox file from HEY.com. When it comes to downloading emails locally, IMAP is better, but HTTP can also do the job.
(*) Funny story. I got my HEY invite from @fragkakis. When I thanked him, he said "I got my Google Wave invite from you, once." :-)