I co-founded ITA Software and have been using some of the proceeds from the sale to Google to fund an email startup. (http://inky.com) The challenges outlined in this thread are all accurate. If you're thinking about putting effort (or money) behind an email startup, think again. I simply don't believe it's doable for a normal startup (i.e., one without a crazy rich guy plowing money into it until it's good enough). The VC-backed "winners" will all get aqui-hired, and then the acquirers will be unhappy because what they bought wasn't actually good enough for prime time.
Here are just a handful of the reasons:
- It is deceptively hard. Like airfare pricing, most people think it's a couple weekends of work, when in fact it's at least 5 years and millions of lines of code to get to a real MVP that someone could use instead of Outlook, Thunderbird or Apple Mail, etc... The set of abstractions required to do it right are unobvious and nontrivial, and you end up with unfixable problems if you don't get them all right. We've rewritten Inky essentially from scratch twice, and only in the current version 3 (circa October 2015) do we finally have the abstractions correct. Look at the Thunderbird bugzilla logs and you will find thousands of bug entries, many of which go on for pages and pages. ITA was similar, by the way: 1996-2001 was basically iteration to get to an MVP.
And because it's not just hard, but deceptively hard, founders and their teams systematically underestimate the effort required, which leads to all kinds of failure modes. Even in the success stores like Mailbox, the teams basically punt on a number of hard problems that really are required for an MVP (like properly sanitizing HTML, supporting Exchange and IMAP "for real", proper support for all the weirdly encoded mail you see in the wild, encrypted mail via S/MIME, etc.)
- The other entities you have to work with are a complete nightmare, and as the client app everything appears to be your fault. Google, Apple, Yahoo, etc. just do whatever the hell they want, randomly, have broken servers they never fix, and place arbitrary problematic restrictions on clients: all limit clients to a small number of connections, and Apple won't let an email app run in the background, so you can't support "real" push notifications without keeping the user's credentials unencrypted in the cloud (which I refuse to do). Google, out of the blue, started banning clients that didn't use oAuth, sending users scary messages about unsafe software. oAuth is great, but just breaking everyone who doesn't support it yet is really, really nasty.
- VCs absolutely hate the space. Email startups have been dogs forever, and every name-brand VC has been burned on a crappy email investment.
- Consumers simply don't care about usability, privacy, or anything else enough to not use what comes with their phones.
- Security-conscious people who might pay for something that's genuinely secure never believe anything is genuinely secure in practice unless it's open source... in which case there is no business model.
- Existing mainstream clients are ironically sticky, because once users develop coping strategies to deal with the quirks of the client they're forced to use, they never want to invest the effort into learning the quirks of a new client.
So why do I work on it? Because in my opinion it's a really important problem that affects billions of people -- and one that needs to be solved properly by folks who are doing it not just as a data harvesting operation, loss-leader to sell devices, or as a way to build a moat around a core offering (search).
> It is deceptively hard [...] The set of abstractions required to do it right are unobvious and nontrivial ...
I would be very interested to hear more about this aspect, if you would be willing to share. I'm always curious about things that sound like they should be simple but end up being surprisingly complicated if you want do do a good job :)
Fascinating! I'd love to read more about the challenges involved in both airfare pricing, and email! Can you link to any posts that go into greater technical detail?
Also, regarding Inky-- I just spent a few minutes browsing your site, and it didn't answer my first question: why should I switch to your product from gmail?
Maybe, but not any time soon. S/MIME solves the same problem and is what enterprises and governments want. It's incredibly complicated and difficult to implement properly, but it does include solutions to some security-related issues that PGP doesn't (e.g., security labeling).
In 1996 there was a huge need for airfare search. Look at the success you've had.
On the contrary email in 2015 isn't a huge need or a pain point for most people.
Since you're entering a crowded market your product has to be 10X better. Currently it's probably not which is why most people perceive Inky as a marginal improvement.
Still I'd love to see other projects you're working on Dave. Clearly you're talented and with the right idea I could see you getting back to where ITA & Crash was.
Here are just a handful of the reasons:
- It is deceptively hard. Like airfare pricing, most people think it's a couple weekends of work, when in fact it's at least 5 years and millions of lines of code to get to a real MVP that someone could use instead of Outlook, Thunderbird or Apple Mail, etc... The set of abstractions required to do it right are unobvious and nontrivial, and you end up with unfixable problems if you don't get them all right. We've rewritten Inky essentially from scratch twice, and only in the current version 3 (circa October 2015) do we finally have the abstractions correct. Look at the Thunderbird bugzilla logs and you will find thousands of bug entries, many of which go on for pages and pages. ITA was similar, by the way: 1996-2001 was basically iteration to get to an MVP.
And because it's not just hard, but deceptively hard, founders and their teams systematically underestimate the effort required, which leads to all kinds of failure modes. Even in the success stores like Mailbox, the teams basically punt on a number of hard problems that really are required for an MVP (like properly sanitizing HTML, supporting Exchange and IMAP "for real", proper support for all the weirdly encoded mail you see in the wild, encrypted mail via S/MIME, etc.)
- The other entities you have to work with are a complete nightmare, and as the client app everything appears to be your fault. Google, Apple, Yahoo, etc. just do whatever the hell they want, randomly, have broken servers they never fix, and place arbitrary problematic restrictions on clients: all limit clients to a small number of connections, and Apple won't let an email app run in the background, so you can't support "real" push notifications without keeping the user's credentials unencrypted in the cloud (which I refuse to do). Google, out of the blue, started banning clients that didn't use oAuth, sending users scary messages about unsafe software. oAuth is great, but just breaking everyone who doesn't support it yet is really, really nasty.
- VCs absolutely hate the space. Email startups have been dogs forever, and every name-brand VC has been burned on a crappy email investment.
- Consumers simply don't care about usability, privacy, or anything else enough to not use what comes with their phones.
- Security-conscious people who might pay for something that's genuinely secure never believe anything is genuinely secure in practice unless it's open source... in which case there is no business model.
- Existing mainstream clients are ironically sticky, because once users develop coping strategies to deal with the quirks of the client they're forced to use, they never want to invest the effort into learning the quirks of a new client.
So why do I work on it? Because in my opinion it's a really important problem that affects billions of people -- and one that needs to be solved properly by folks who are doing it not just as a data harvesting operation, loss-leader to sell devices, or as a way to build a moat around a core offering (search).