Why email startups fail
forwardemail.net
forwardemail.net
This means spammers, right?
That's another name for spam.
I'm sure you'll get mostly useful feedback.
But it almost never is, isn't it?
https://www.forbes.com/sites/panosmourdoukoutas/2017/02/24/a...
Me personally I won't give a pass to business with an unsubscribe link, I have extreme disgust that we're in some make-believe pretend world that I asked for this in the first place
You'll get a link to unsubscribe (to just that campaign), or unsubscribe, but somehow get your email back into the victims table.
The fact that you have to frame it your way speaks mostly to the fact that apparently your income depends on spam being seen as acceptable and not a scourge to humanity. But that's just my perspective...
Define "low quality" and "not liked". Each person will classify a given message differently. At least in the general case it's hardly realistic to expect a sender to classify a message from the perspective of a specific recipient prior to sending it.
On the other hand, it is reasonable to expect addresses to be acquired via legitimate means (ie collected only with the consent of the recipient) and to cease attempts at contact when requested. That's essentially the boundary between reasonable conduct and harassment.
> At least in the general case it's hardly realistic to expect a sender to classify a message from the perspective of a specific recipient prior to sending it
I guess from the perspective of someone doing mass mailings that is true. A pointer to what I assume is your bias on the topic. But from the perspective of the recipient, who actually has to invest the cognitive effort of reading that message, I think it's only natural to expect a certain amount of average value out of that effort. And lets be honest, that mass mailing doesn't usually deliver that. It's just another trigger designed to manipulate people into buying shit they didn't even really want.
Let's rather have the default newsletter checkbox to be "off" and legal repercussions for repeated offenders, then I'll be on board for the term "reasonable conduct" too.
i.e. juggle between allowing allowing some paid spam and not being outright blocked by google/microsoft. That's the service they provide: VC-backed connections to get traffic unblackholed on behalf of their spammer customers.
>There are plenty of things I subscribe to which are marketing emails I want to see.
Therefore: that's how I feel about my e-mail, meaning let's send a billion messages a day, surely a billion people also feel same as me about it.
This is something that shocked me when I built https://mailpace.com I just assumed that everyone doing email ran their own smtp servers. Turns out YC and others are funding wrappers on aws ses left right and center!
A groundbreaking innovation that will totally disrupt everything including pizza delivery!
Given what a giant pain in the ass (for good reason, fuck spam) it is to get into the Gmail inbox I can understand why the spammers do it.
I have forward/backward dns configured as well as dkim, spf, etc. With TLS endpoints configured for secure transmission. It's worked pretty well in general. That said, I'm not using it that much, and there's no spam coming from my server (dedicated box on OVH), I dedicated a VM/IP to the mail server.
No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points: bloated Electron apps that just about everyone on the planet has installed on their computers. I personally hate React, but technology decisions are irrelevant to the long-term success of startups. (As long as they don't grossly interfere with customer experience, the feature set, etc.)
> Final Warning: After analyzing hundreds of email startups, the evidence is overwhelming - 80%+ fail completely. Email isn't broken, and trying to "fix" it is a guaranteed path to failure.
First, I'd bet money that figure is actually wrong: the failure rate is likely way higher than 80%. And I'm honestly not sure how anyone could seriously think a 20% exit rate is bad in just about any vertical (but especially a "boring" one like email).
> Resources: Volunteer developers can't sustain enterprise-level software
What am I even reading here? Author does realize openssl[1], Linux[2], and many other "enterprise-level" pieces of software are entirely (or almost entirely) maintained by volunteer developers, right?
Anyway, the post had its opposite intended effect on me: it made me think about ways I could reinvent email.
If all you do is run games and discord on your home PC memory consumption won't matter.
If you have multiple uses or work from home ... Discord expanding to 4 G to display the meme channel with all those cat photos will be annoying to say the least.
Case in point, I stopped running Discord on my laptop. Still run it on a desktop to keep in touch with some people, but it's not my default goto for any communication.
Also, just because most users don't know better, it doesn't mean that Electron apps aren't basically disrespecting the user's resources and passing needless costs to them. Especially if you have hundreds of million users the extra cost they pay dwarfs whatever you the app developer would have paid for a working native application.
The amount of people who won’t adopt based on pricipal is exceedingly small.
i guess im the one guy left that has neither
edit:quote
This is just flat out false. Even my girlfriend - the least tech interest person I know - complained to me how its possible that a damn chat app (teams) is bad enough to make her entire computer feel slow.
So yeah, average users maybe don‘t hate Electron or React, bad many people hat the bad user experiences these solutions often entail.
The real question is; has your girlfriend stopped using teams since finding out how slow it is?
> The real question is; has your girlfriend stopped using teams since finding out how slow it is?
Don't know about his girlfriend, but two companies I was at did (one stopped with MS Teams, one with Slack).
I disagree. The crux of his argument was slowness, sure, but that's not why these applications fail because as I said, unless you know what to look for (Electron and React being the two main offenders), by the time you've found out that the application is slow, you're "locked in". Leaving these kinds of software after you've got setup with them is a lot more effort than starting with them. Email arguably more than any other, but messaging apps like Teams and Discord also suffer from this network effect.
That is the neat part. Teams, Slack and some other applications within that realm aren't actually something that we're choosing to use. It usually is something that is imposed onto us by the organization you're working for. With discord the effect is different, but the consequence is the same. Network effects basically force you to be on Discord.
At least in my department, Microsoft Teams is universally hated by everyone (that's only n=60). But we don't really have a choice in using it and we never had a say in the matter when the software was bought. With teams especially, it's basically an open secret that Teams is frequently only bought because its basically packaged in with an Microsoft 363 subscription.
And because of how software like this is imposed, I don't think the size of the user base serves as a good proxy to judge how well liked a piece of software is, at least in the enterprise space. For B2C apps, the effect may be less strong to non existent, but I would argue that the network effects of some apps can act as a similarly strong force.
In our case, we see Salesforce as our biggest competitor, so we did not want our corporate history on Slack (I don't think that's particularly a high risk issue, but our leadership does, so... Teams it is.)
And because they don't know, the heat is in somebody else. Like the tech support, or windows, or internet, or the anti virus or whatever (because even some tech support, if even exist, don't know but surely have a theory about it).
Let me tell you an example: When the local network, cloud flare, printer, windows, their firewall, etc fails and by coincidence they are using our app. they call US.
And blame US.
A sizable portion of the support calls that are handled by any provider of tech for small companies is about other peoples software.
Worked at two companies full of "real" users who cared enough to look elsewhere.
Yes I know it's easy to find exceptions to every argument, but it's worth pointing out that it's such a bad experience that even some "normal" people care.
And, even more on point, so is Postfix!
This is actually better than overall failure rate. At 80% I would absolutely be investing in more email companies!
The entire analysis is skewed to satisfy their own messaging or perhaps internal motivation. Mentioning Cyrus IMAP and SpamAssassin is ... being stuck in a time warp.
Being self-funded, their position is not surprising. However they really need some perspective.
Small team yes, but one person? https://runbox.com/about/runbox-team/ indicates otherwise. (I am a happy customer.)
Around 2008, tried to M&A regional email providers that served commercial and government enterprises throughout UK and Europe onto a more secure, standardized, and centralized infrastructure with lower employee count.
Totally obliterated by GMail and Hotmail because competing with (almost) free on something people really don't want to change once established is really, really hard even if you're gobbling up the supply-side.
Maybe it scales where there are compliance aspects like ProofPoint, but otherwise people don't want to change utility infrastructure without a big win or significant existing pain.
Times have changed but getting people to move on low cost commodity utilities with lots of options is almost like going into the restaurant industry.
I agree that "reinventing" email, or building a business based on "AI features" are both terrible ideas.
We began building Marco not to do either of these things, but simply because _there wasn't_ any actual cross-platform IMAP client.
Apple Mail exists (but is terrible) if you only have Apple devices. Lots of other options like Superhuman and Shortwave exist, but only support Gmail+Outlook.
All we're doing is building the app that should have existed 10 years ago: a cross-platform, offline-first "Thunderbird". Except far more lightweight and modern. And yes, we've built it from the ground up. And no, it's not Electron.
> it became clear that they are developing a single web application, and then wrapping it with CapacitorJs to run on native platforms.
So what's the difference? When complaining, Electron is a generic term for instantiating a whole -ing browser to display a RecyclerView (in Android terms). Not necessarily a complaint about Electron in particular.
> offline-first
Humm. Does that mean you plan to interpose your own server between the app and imap? I sure hope not.
If you mean you keep a local copy of the emails, that's about how any decent email app works. Even Apple mail can do it for gmail over imap :)
I may actually be a potential customer, I'm just pessimistic. Not a fan of "join the waitlist" marketing either.
By the way, how much is a latte where you live?
Yes, we have a server runtime between the client app and the upstream IMAP provider. As does Superhuman, Missive, and any other product that actually provides push notifications. For users that see this as a non-starter, we enthusiastically recommend local-only clients – Thunderbird, Talanoa, etc.
The waitlist is not marketing. We are in alpha right now and are genuinely not ready for GA. As soon as we are, the waitlist will disappear.
No, I do not live in the bay area, or even the US.
You may consider toning down the negativity in the future.
... but is there any difference wrt to runtime ram usage? It's still javascript. In my experience as a user forced to use electron apps, the runtime is a fixed ram cost but then the application expands and expands and expands...
> You may consider toning down the negativity in the future.
Sorry, but I just want to read my damn email. I'd pay for that [1] since as you yourself said, Apple Mail sucks.
I do not need any extra services and especially not a dependency on another server between my email client and my email server.
Guess it's still Apple Mail or Thunderbird (Talanoa does not seem to mention working with standard email protocols). Or ssh in and use mutt :)
[1] Clearly not as much as a SV latte per month.
> Sorry, but I just want to read my damn email
The good news is that there are literally dozens of email client options. If cross-platform sync and push notifications don't matter to you, Apple Mail and Thunderbird are good options.
Talanoa indeed operates via Google and Microsoft APIs, not IMAP/SMTP.
JS needs some "evangelists" to explain this to people like me :)
> cross-platform sync
Um, if you use 5 clients to connect to the same imap server, you have "cross-platform sync" already don't you? It does seem to work for me.
> Apple Mail and Thunderbird are good options.
At this rate I'll probably become a donator/contributor to Thunderbird in at most two years :)
Cross-platform sync and push notifications are literally part of IMAP.
You are conflating things. IMAP supports IDLE, NOTIFY, and _sometimes_ P-IMAP, but IMAP is never going to trigger a push notification on your iPhone/Android.
I cannot see that not being a non-starter for anyone that actually understands it.
Everyone has their own threshold/requirements for privacy.
I completely understand your viewpoint, to be clear.
If we had a team of ten, we'd certainly be writing fully-native apps.
Linear, Slack, Discord. The discussion goes on ad nauseam. This thread is about email, not electron.
She still uses Thunderbird, but she stopped checking her email.
What a piece of software. I remember when I migrated from Outlook Express to Thunderbird 20+ years ago because Outlook Express had a bad habit of being vulnerable to exploits just by receiving them; you didn't need to even open the email, or download an attachment, or open the attachment. It was enough for the email program to be open upon receiving malware, and it'd automatically get it.
I've been using FastMail's mobile app and web app for 5-10 years now.
I wish there was something better, but it's good enough.
Asking for less makes me less focused on email, which is not bad.
Perhaps you don't like the conclusions it draws?
You then put words in others mouths. Then cannot leave the thread alone. You've already been called out by failing to pander some cheap anti-Electron sloganeering to the HN crowd, too.
I suggest, if you're going to talk-up your APP, to do so by focusing on positives. Perhaps read some posts by people that promote successfully, such as patio11.
I am not putting words in anyone's mouth. Direct quotes from the article:
> The companies that actually succeed in email don't try to reinvent the wheel
> Adding "AI" doesn't solve email's fundamental non-problems
Also, the article itself details the "Electron Performance Crisis".
Draw your own conclusions – this is a discussion. We're discussing.
Most of the large marketing ecommerce/enterprise market was captured via ExactTarget/Salesforce, Oracle/Responsys/Eloqua, IBM/SilverPop/Acoustic, Adobe/Neolane/Marketo by the mid 2010's.
SendGrid/Twilio was another a few years later, Amazon SES is ok, then you have some of the smaller market players (MailChimp, Constant Contact, etc).
Hard to scale/grow a startup in any real way when there are so many fairly well entrenched solutions across industries and company sizes.
Something I’d die for someone to tackle.
OMG. How can someone say this in the age of AI spam. Legitimate emails categorized a spam. Impossibility to run independent email servers because getting blocked by the big players. Forced subscriptions to mailing lists. Tracking through images....
The article is AI spam
If I get Quantum Leaped back into my younger self, I'll start working on fixing email around 1993.
The article kinda acknowledges that it’s a shitheap that’s awful to implement, but somehow still champions the idea that it all works fine.
And what’s with the repeated jabs at the “terrible” exit rate that actually seems pretty good?
The underly technology is very reliable. Email not getting delivered to the recipient is more about low/no-cost providers preferring to filter almost all messages rather than spend money on doing a good job of spam filtering.
I will never understand where this sentiment comes from. I've run my own mail server for like 7 years at that point. It's so incredibly rare for my mail to not deliver that I can't remember the last time I had to debug it. The most annoying thing I've had to deal with was dovecot breaking compatibility with their config format, but even that was a couple of hours of work to get back on track.
My most surprising experience was when I broke the mail setup while migrating servers once. Postfix was down for something like 7 days before I got around to fixing it. The cool thing was what happened after I fixed it. While my server was down, the other relays had been dutifully holding onto my mail, waiting for me to once again accept it. So after a week of downtime, I still got all my mail within 24 hours after starting up my server again.
That's fucking reliable in my book.
May I know what is so "terrible" about those protocols ans what "technical debt" are you talking about?
> Vendor quirks are everywhere, and it’s incredibly unreliable
That has nothing to do with actual email protocols. Generic email protocols are extremely reliable and resilient to any sorts of disruptions. I wish any of modern protocols exhibit similar simplicity and reliability.
But of course if vendor would like to add their quirks and you would like to buy that - that's your choice innit.
POP is pretty archaic and lack support for multiple clients accessing the same account.
IMAP is complex, slow and lack modern email futures threading, contacts. Clients often implement it in inconsistent matter, given there are plenty of extensions.
SMTP is not a single protocol but collection of bolted on protocols (DMARC, DKIM, SPF). Lack delivery tracking, and it is very opaque when it comes to spam filtering.
All these protocols are build on top of raw TCP. It is harder to implement any things we take for granted in http like: encryption, compression, multiplexing and debugability are not there by default.
> That has nothing to do with actual email protocols. Generic email protocols are extremely reliable and resilient to any sorts of disruptions. I wish any of modern protocols exhibit similar simplicity and reliability.
People spend decades building infrastructure, but even then only hardcore graybeard will self-host email.
There are no issues with POP and multiple clients whatsoever.
> IMAP is complex, slow and lack modern email futures threading, contacts.
What's "complex" about IMAP? Extremely simple and reliable protocol. Contacts are not part of IMAP and handled by different protocols.
> SMTP is not a single protocol but collection of bolted on protocols (DMARC, DKIM, SPF).
I suggest you to educate yourself on DKIM, DMARC, SPF and SMTP before making those statements.
> Lack delivery tracking, and it is very opaque when it comes to spam filtering.
It DOES have delivery tracking. Spam filtering is not a protocol feature and it shouldn't be. I suggest you again to educate yourself.
> All these protocols are build on top of raw TCP. It is harder to implement any things we take for granted in http like: encryption, compression, multiplexing and debugability are not there by default.
Let me tell you one of most hidden secrets in the industry - EVERYTHING we have online is built on top of raw TCP. Ok, and UDP as well. Every bloody fancy JS framework or mobile app you can think about is written on top of that raw TCP. Crazy world huh?
> People spend decades building infrastructure, but even then only hardcore graybeard will self-host email
If you don't know how to build something doesn't mean it's left out to "hardcore graybeards". You got to admit you just don't know how and either learn or surrender to companies who know, offering the same for a buck. It's pretty simple.
POP3 in standard only have "Leave a copy on the server" but lack synchronisation mechanism.
> I suggest you to educate yourself on DKIM, DMARC, SPF and SMTP before making those statements.
You cannot use SMTP in real world without these protocols. Your messages would automatically land in spam folders of big providers. For example, if you want to send email to Gmail, you need SPF and DKIM [1]. Any half decent implementation of SMTP need to support all these protocols [2].
[1] https://support.google.com/a/answer/81126?hl=en
[2] https://github.com/stalwartlabs/stalwart
> It DOES have delivery tracking. Spam filtering is not a protocol feature and it shouldn't be. I suggest you again to educate yourself.
SMTP have extension for DSNs (Delivery Status Notifications) but crucially it does not provide information if/why email was classified as spam. This is a reason why many website registration form have “check spam folder”. SMTP deliverability is a hard problem both on protocol level and infrastructure on spam filtering[3].
[3] https://blog.paranoidpenguin.net/2020/02/self-hosting-email-...
> If you don't know how to build something doesn't mean it's left out to "hardcore graybeards". You got to admit you just don't know how and either learn or surrender to companies who know, offering the same for a buck. It's pretty simple.
I spend a significant amount of time investigating feasibility of building an email product and build some libraries for email protocols. It is not just my opinion but other HNs users including OP. Search HN for "self hosting email" for others people experience.
Would you explain what do you mean under the "synchronisation mechanism"?
> You cannot use SMTP in real world without these protocols.
You absolutely can. GMail is not the only email provider out there.
> SMTP have extension for DSNs (Delivery Status Notifications) but crucially it does not provide information if/why email was classified as spam. This is a reason why many website registration form have “check spam folder”. SMTP deliverability is a hard problem both on protocol level and infrastructure on spam filtering[3].
I find it hard to even start commenting this, only can suggest you again to educate yourself. Spam related matters were never a part of transport protocol. And never will be for obvious reasons. Just because you would like them to be, it won't change anything.
> I spend a significant amount of time investigating feasibility of building an email product and build some libraries for email protocols. It is not just my opinion but other HNs users including OP. Search HN for "self hosting email" for others people experience.
Happy for you to actually explore building software, but we can't carry discussions just because some HN users carry some, possibly erroneous opinions, or can we?
lol thanks but no thanks
10% of attempts to monetize new ideas might just be a basal level, since the root issues (humans, often without formal business training nor experience) don't change with technological implementation.
The average user receives 86 emails per day?! And I get a bit overwhelmed if I receive more than 3. Kinda puts things into perspective :-)
So don't feel too overwhelmed!
Yeah the fundamental thing is email does it's job, and if you want to change that job in any dramatic fashion ... it no longer does its core job.
But fundamentally the "folder" view of email does not work. A single message often needs to be in several different folders simultaneously. And when the thread is spread across many folders, there needs to be a way to see the whole thread.
The only way to accomplish this is with email tags or labels. These are implemented by nearly all successful email companies. Gmail, Fastmail, and Proton are examples. Labels are a fundamental feature in this day and age, and neither IMAP nor POP can handle them gracefully.
Gmail is so big that when Outlook, Apple Mail, and even Thunderbird connect to it, they do an OAuth exchange and then talk over a proprietary protocol.
JMAP may have poor adoption, but it's the only open protocol that understands labels well. The lack of adoption is mostly due to email providers not implementing it. There is not a lot of incentive for clients to implement it for the few providers. And providers would prefer you use their web clients anyway, as then they control access to your email.
Can you elaborate? Anything I can read on this?
Citation needed. This has never occurred to me.
> And when the thread is spread across many folders, there needs to be a way to see the whole thread.
Already possible, at least in Thunderbird.
> Labels are a fundamental feature [...] and neither IMAP nor POP can handle them gracefully.
IMAP has user-defined labels, whats wrong with them?
An underrated feature of IMAP is that you can attach notes to mails.
Just No. This is by far my biggest complaint of using Gmail.
It makes it impossible to write rules to file mail into folders as all you can do is add tags (labels). Whereas to _move_ you require the ability to unset and label which tags/labels don't support as thats a definining function of a folder.
Make Email Great Again! Now thats a campaign i'd be willing to fund!
Both the Gmail web interface and the Gmail API allow the ability to set all the labels for a message. This can effectively enable your desired functionality. But IMAP can only deal with "folders", and cannot correctly decide when to remove a single label or remove all other labels when it sees a move action.
IMAP also only deals in messages and not threads. Gmail labels also technically only apply to messages, but the web interface shows the union of all labels of a thread. This is another decision I agree with. It means that when someone explicitly adds me to a thread, the whole thread gets highlighted in my feed.
I personally really enjoy the Gmail/fastmail/proton behavior so please don't make another political campaign to make things worse again. We have enough of those.
Am I way off with my numbers there?
Gmail's threading is an abomination.
"If you want to fork a thread, just change the subject!" This idea is so brain-dead and antithetical to deep mailing list conversations.
"Oops too many people replied, guess gmail'll fork the thread without changing the subject"
My disdain for this misfeature is palpable.
For the founders and their investors, that’s nut a bug it’s a feature
I think they need one of those star studded benefit concerts for them (oh, wait. It just occurred in Venice last weekend)
There’s a perverse lesson there.
How is this different than startups in any other space? How do you define success?
Also, SaneBox has been around for a lot longer than they mentioned. And their criticism is it’s not revolutionary enfough?