I was engineer 12 at SendGrid and left after IPO and subsequent acquisition by Twilio. Being infrastructure and the backing many email marketing companies, we did really well. Kind of like selling shovels in the gold rush. We struggled more on the product front breaking into the much larger marketing space. Learned a lot there leading and scaling teams and scaling the email infrastructure to support over 8 billion daily sends.
No, in order for their traffic to not get blackholed, places like sendgrid have to follow the rules and make their customers follow the rules. The marketing emails they send will be somewhere between things people actually want to see and mildly annoying. There are plenty of things I subscribe to which are marketing emails I want to see.
> places like sendgrid have to follow the rules and make their customers follow the rules
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.
It's a classic example of anecdotal framing. Email traffic is blackholed by default and these mass-emailing services are needed precisely because majority of email traffic is marketing and majority of that subtraffic is spam.
Perhaps historically, but these days I think spam refers to senders that don't play by the rules. Unsolicited (ie didn't obtain the recipient's address in a legitimate manner), no unsubscribe link (or not honored), technical measures intended to circumvent various filters, etc.
The ugly and awkward thing about the unsubscribe link is I never subscribed in the first place. Someone else did on my behalf. To even ask to be unsubscribed, I feel, is taking some ownership of the subscription and playing into a crooked system. It's like being sent an invoice for something I never ordered and needing to cancel the invoice. And even if you say, "buzz off", who is to say someone won't decide to "resubscribe" you next day, given it's outside your control.
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
I’m with you. I learned about the concept of “implicit opt-in / consent” while I was building an email marketing feature on a platform and I found the concept disgusting, but was told that because it’s technically legal, our customers considered it table stakes.
You may define it that way, but the original property of spam seems to apply nevertheless: They are low quality and noone really likes them.
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...
That's a rather baseless assumption about my income. Does it really seem so unlikely to you that a reasonable person might not use the exact same criteria as yourself? Why are you so confident in the generalization of your own perspective to the population at large?
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.
If I want certain marketing emails for these purposes, I create a rule to mark it read on arrival and moved directly to a certain folder where I can find it when needed. It will still never see my inbox.
More likely bacn than spam. Stuff that you agreed to receive, but don't especially want. Even though people don't really want bacn, it's the compromise that society has generally accepted in terms of drawing a line against spam while still catering to allegedly legitimate marketing.
> Every single "email startup" is just building UI on top of existing infrastructure. They're not building actual email servers - they're building apps that connect to real email infrastructure.
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!
Dunno... I'm running a mailu box, without delivery issues to Gmail... now Outlook.com hosted mail (not o365) is another story.
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.
This just isn't true. For some reason everyone keeps repeating it anyway, I suspect because they haven't tried it and someone told them confidently it wasn't practical.
> Electron Performance Crisis: Modern email clients built with Electron and React Native suffer from severe memory bloat and performance issues. These cross-platform frameworks, while convenient for developers, create resource-heavy applications that consume hundreds of megabytes to gigabytes of RAM for basic email functionality.
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).
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.
> No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points
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.
I am a real Discord customer who is actively looking for an alternative due to how terrible the performance is on my M1 MacBook and on my gaming PC. I'm just one person—I'm not claiming to represent the 'average' customer. But I am part of the average.
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 whole thesis OP is making is that this isn’t really true, evidenced by real world behaviours. Electron apps have some of the highest market share, even the worlds most popular ide is an electron app.
The amount of people who won’t adopt based on pricipal is exceedingly small.
> No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points:
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.
There's a slight difference, real customers care if the software feels slow, not if its using Electron or React. You might argue that they're one in the same, and I wouldn't disagree, but they don't know that (or arguably care about that), and so don't know what to look for and what to avoid. By the time they realise the software they're using is slow, they're often too embedded in it to quit for that reason alone.
The real question is; has your girlfriend stopped using teams since finding out how slow it is?
> The argument was the slowness, not the name of the technology
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.
> The real question is; has your girlfriend stopped using teams since finding out how slow it is?
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.
That's very true, I suppose my point was less that these kinds of software are well liked, but more so that the effort of leaving them outweighs the gains in the performance alone for a lot of users. But you're right, the argument doesn't really hold up for Teams because you rarely have a choice in the matter. Discord there is some choice, you can organise your friends and groups to leave, but its a monumental effort.
> 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.
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.)
Yeah. "No (real) customer has ever, or will ever, care about this. ", in fact means "No (real) customer has ever, or will ever, knows how to care about this".
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.
Yes, but couldn't you to market it as 'four times faster than teams', 'no action will ever take longer than 5 ms' 'enables cross-referencing many e-mails without delay-- other software can take half a second to bring up an e-mail', etc?
> 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?
I’m surprised Hey isn’t mentioned. That’s the only example I know of someone recently trying to reinvent email. Maybe it wasn’t included because it’s part of Basecamp and not its own company. But I think it’s important to discuss if your argument is that “no one has successfully reinvented email”.
> Techstars alone has 28 email-related companies with only 5 exits - an exceedingly high failure rate (sometimes calculated to be 80%+).
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.
If Fastmail is included in the startup category, why aren’t email companies like Posteo and Mailbox.org included? Runbox.com is a one person operation. They’ve all been around for decades and are still going strong. Posteo hasn’t even taken any VC investment (which could be one reason, as the article points out, for failure). Migadu has been around for quite sometime and doesn’t find a mention in this list.
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.
My mom would have been thrilled when she was still in the workforce 10 years ago.
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.
> 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.
I think you're conflating Electron apps with hybrid apps. Electron literally bundles Chrome and NodeJs, resulting in apps that are 300mb+. The Marco macOS app is 3mb.
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.
> Electron literally bundles Chrome and NodeJs, resulting in apps that are 300mb+. The Marco macOS app is 3mb.
... 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 :)
Yes, there is a massive difference in runtime RAM usage.
> 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.
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.
Totally agree with you. I take the post being mainly self-promotion with the hook of being "non-electron" for the HN crowd. They still like writing in 1 language and not worry about platforms, just not using the thing called electron.
You seem to be chatting down some perceived tangental competition in order to chat yourself up. That kind of self-promotion's no good. Especially when picking ethereal "your writing sounds weird" ad homineming a decently detailed, reasonably hard-hitting, article.
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.
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.
There’s still a huge opportunity for AI. The way it’s used currently (sorting & drafting replies) is barely scratching the surface. Until you can literally turn your mailbox over to AI the way you would with a human assistant, email UX is not a solved problem.
I'm far from an expert but I would say there will always be people who hate the current enshitified solutions and are looking for the new cool kid in town
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....
We’ve worked on email infrastructure for multiple clients at Axon, and everything in this write-up checks out. Most startups just build wrappers around Postfix or SES and call it innovation. The hard problems, such as spam filtering, deliverability, and auth protocols, never get touched. That’s why 80% fail.
This is a weird article. Email is a hodgepodge of terrible protocols that have progressively had more and more technical debt laid upon them for decades and decades. Vendor quirks are everywhere, and it’s incredibly unreliable. Its defining quality – it’s decentralisation – has been beaten out of it by IP reputation so everybody ends up sending through a handful of providers.
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?
> Email is a hodgepodge of terrible protocols that have progressively had more and more technical debt laid upon them for decades and decades.
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.
> May I know what is so "terrible" about those protocols ans what "technical debt" are you talking about?
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.
> POP is pretty archaic and lack support for multiple clients accessing the same account.
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.
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.
> Quantum-Safe Email Security: Forward Email is the world's first and only email service to use quantum-resistant and individually encrypted SQLite mailboxes
Average startup success rate is 1/10 at best. The "90% of startups fail" metric that's often cited is likely inflated by B2B companies which find significantly more success (like, an order of magnitude more) than B2C.
Not sure that's inflated, as it's comparable to the 5-year failure rate of new storefront businesses, according to what I read in the pre-internet days.
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.
I wouldn't say Sparrow failed -- it got bought because it was successful. Did it reach its full potential? Certainly not. But certainly Google determined that it potentially could or it wouldn't have spent $MM to kill it.
Long article, but the fundamental premise is that IMAP, SMTP, and POP are all you need. And that email clients are good... This is just false IMHO. There is a reason why both Fastmail and Gmail implement their own protocols in addition to those.
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.
> 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.
>A single message often needs to be in several different folders simultaneously
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!
This again is a limitation of mapping labels to IMAP, which does not understand labels.
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.
Actually recent email innovation I enjoyed is Mimestream, the macOS native client for Gmail. Apple’s smart inbox is half baked but better than nothing.
Cloudflare now also has a pretty good email forwarding service.
Is 80% even that high? I thought the idea behind VC was to fund companies where 90% are doomed to fail, 9% might do okay, in order to cash in big on the 1% that have stellar success.
My god this "article" is an inconsistent pile of AI slop.
It actively contridicts itself and changes the thesis several times as it goes on and on and on.
Yet somehow ranked on this site, made it to my inbox, and was intriguing enfough for me to read until they end. Something that’s maybe true for 5% of the articles I get sent (which composes the top 30 HN articles of the previous 24 hours).
It definitely is. Click the links that go to HN comments, in the section about how the community is right. Not one of them is anything to do with email.
While it may be true most email startups fail, rolling over and saying the UI has been solved is a bit defeatist IMO. Does the author even know about hey.com?
I was engineer 12 at SendGrid and left after IPO and subsequent acquisition by Twilio. Being infrastructure and the backing many email marketing companies, we did really well. Kind of like selling shovels in the gold rush. We struggled more on the product front breaking into the much larger marketing space. Learned a lot there leading and scaling teams and scaling the email infrastructure to support over 8 billion daily sends.
> email marketing companies
This means spammers, right?
No, in order for their traffic to not get blackholed, places like sendgrid have to follow the rules and make their customers follow the rules. The marketing emails they send will be somewhere between things people actually want to see and mildly annoying. There are plenty of things I subscribe to which are marketing emails I want to see.
> places like sendgrid have to follow the rules and make their customers follow the rules
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.
exactly, then a leader says:
>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.
It's a classic example of anecdotal framing. Email traffic is blackholed by default and these mass-emailing services are needed precisely because majority of email traffic is marketing and majority of that subtraffic is spam.
"mildly annoying"
That's another name for spam.
Perhaps historically, but these days I think spam refers to senders that don't play by the rules. Unsolicited (ie didn't obtain the recipient's address in a legitimate manner), no unsubscribe link (or not honored), technical measures intended to circumvent various filters, etc.
I agree. These days I don't report email as spam if it has a (working) unsubscribe link.
Oh, so a day is not rainy if your coat dries after it?
No, rain is still rain. I just stopped complaining about it as it rains 24/7.
The ugly and awkward thing about the unsubscribe link is I never subscribed in the first place. Someone else did on my behalf. To even ask to be unsubscribed, I feel, is taking some ownership of the subscription and playing into a crooked system. It's like being sent an invoice for something I never ordered and needing to cancel the invoice. And even if you say, "buzz off", who is to say someone won't decide to "resubscribe" you next day, given it's outside your control.
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
I’m with you. I learned about the concept of “implicit opt-in / consent” while I was building an email marketing feature on a platform and I found the concept disgusting, but was told that because it’s technically legal, our customers considered it table stakes.
You may define it that way, but the original property of spam seems to apply nevertheless: They are low quality and noone really likes them.
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...
That's a rather baseless assumption about my income. Does it really seem so unlikely to you that a reasonable person might not use the exact same criteria as yourself? Why are you so confident in the generalization of your own perspective to the population at large?
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.
marketing emails are mildly annoying until you want to buy something and they become useful for the 20% coupon
If I want certain marketing emails for these purposes, I create a rule to mark it read on arrival and moved directly to a certain folder where I can find it when needed. It will still never see my inbox.
Most people don't know what a rule is.
Or the band you love is in town
Sure, would you be kind enough to publish your personal phone number on this public thread?
I'm sure you'll get mostly useful feedback.
I own and operate a public facing company with my name on it. This is already the case. Par for the course.
Or there is a discount for Viagra
That's what opt-in is for.
But it almost never is, isn't it?
What if the product just cost 20% less in the first place?
Then your company crashes in sales.
https://www.forbes.com/sites/panosmourdoukoutas/2017/02/24/a...
More likely bacn than spam. Stuff that you agreed to receive, but don't especially want. Even though people don't really want bacn, it's the compromise that society has generally accepted in terms of drawing a line against spam while still catering to allegedly legitimate marketing.
Looking for a job, I see :P
> Every single "email startup" is just building UI on top of existing infrastructure. They're not building actual email servers - they're building apps that connect to real email infrastructure.
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!
> 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!
> Turns out YC and others are funding wrappers on aws ses left right and center!
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.
Dunno... I'm running a mailu box, without delivery issues to Gmail... now Outlook.com hosted mail (not o365) is another story.
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.
This just isn't true. For some reason everyone keeps repeating it anyway, I suspect because they haven't tried it and someone told them confidently it wasn't practical.
My first thought was wow - 20% of email startups succeed? That’s actually pretty good.
> Electron Performance Crisis: Modern email clients built with Electron and React Native suffer from severe memory bloat and performance issues. These cross-platform frameworks, while convenient for developers, create resource-heavy applications that consume hundreds of megabytes to gigabytes of RAM for basic email functionality.
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.
[1] https://github.com/openssl/openssl
[2] https://github.com/torvalds/linux
> No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points
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.
I am a real Discord customer who is actively looking for an alternative due to how terrible the performance is on my M1 MacBook and on my gaming PC. I'm just one person—I'm not claiming to represent the 'average' customer. But I am part of the average.
The other part of the average is the 200m+ monthly active users who can't seem to find the uninstall button.
It really depends.
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 whole thesis OP is making is that this isn’t really true, evidenced by real world behaviours. Electron apps have some of the highest market share, even the worlds most popular ide is an electron app.
The amount of people who won’t adopt based on pricipal is exceedingly small.
> No (real) customer has ever, or will ever, care about this. Discord and Slack are pretty much case-in-points:
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.
There's a slight difference, real customers care if the software feels slow, not if its using Electron or React. You might argue that they're one in the same, and I wouldn't disagree, but they don't know that (or arguably care about that), and so don't know what to look for and what to avoid. By the time they realise the software they're using is slow, they're often too embedded in it to quit for that reason alone.
The real question is; has your girlfriend stopped using teams since finding out how slow it is?
The argument was the slowness, not the name of the technology. He only mentioned named it because _we_ all know the relationship.
> 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).
> The argument was the slowness, not the name of the technology
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.
> The real question is; has your girlfriend stopped using teams since finding out how slow it is?
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.
That's very true, I suppose my point was less that these kinds of software are well liked, but more so that the effort of leaving them outweighs the gains in the performance alone for a lot of users. But you're right, the argument doesn't really hold up for Teams because you rarely have a choice in the matter. Discord there is some choice, you can organise your friends and groups to leave, but its a monumental effort.
> 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.
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.)
Yeah. "No (real) customer has ever, or will ever, care about this. ", in fact means "No (real) customer has ever, or will ever, knows how to care about this".
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.
Yes, but couldn't you to market it as 'four times faster than teams', 'no action will ever take longer than 5 ms' 'enables cross-referencing many e-mails without delay-- other software can take half a second to bring up an e-mail', etc?
> 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?
And, even more on point, so is Postfix!
> bloated Electron apps that just about everyone on the planet has installed on their computers
i guess im the one guy left that has neither
edit:quote
I’m surprised Hey isn’t mentioned. That’s the only example I know of someone recently trying to reinvent email. Maybe it wasn’t included because it’s part of Basecamp and not its own company. But I think it’s important to discuss if your argument is that “no one has successfully reinvented email”.
It is mentioned, there's an entire section named "The HEY Experiment".
By reinvent are you referring to UX? Fastmail is reinventing email through superior open protocols.
JMAP is mentioned in the article (negatively)
UX is what made the difference between the first iPhone and a palm.
We have regressed as a society.
Obligatory “as far as the customer is concerned, the interface is the product”
> Techstars alone has 28 email-related companies with only 5 exits - an exceedingly high failure rate (sometimes calculated to be 80%+).
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.
If Fastmail is included in the startup category, why aren’t email companies like Posteo and Mailbox.org included? Runbox.com is a one person operation. They’ve all been around for decades and are still going strong. Posteo hasn’t even taken any VC investment (which could be one reason, as the article points out, for failure). Migadu has been around for quite sometime and doesn’t find a mention in this list.
Because the "AI" wasn't trained on enough mentions of those :)
> Runbox.com is a one person operation.
Small team yes, but one person? https://runbox.com/about/runbox-team/ indicates otherwise. (I am a happy customer.)
Mailbox raising 6M, having a 100M exit and getting called out failure is crazy
Rapportive listed at having raised $120k for a $15m exit also stands out.
Been There, Done That, Bought The T-Shirt.
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.
It seems Forward Email has come to the exact same conclusion I did in a blog post awhile back: https://marcoapp.io/blog/marco-an-introduction
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.
https://marcoapp.io
My mom would have been thrilled when she was still in the workforce 10 years ago.
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.
> 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?
I think you're conflating Electron apps with hybrid apps. Electron literally bundles Chrome and NodeJs, resulting in apps that are 300mb+. The Marco macOS app is 3mb.
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.
> Yes, we have a server runtime between the client app and the upstream IMAP provider.
I cannot see that not being a non-starter for anyone that actually understands it.
Superhuman, Shortwave, Missive, Spark, HEY, Canary, Zero.
Everyone has their own threshold/requirements for privacy.
I completely understand your viewpoint, to be clear.
> Electron literally bundles Chrome and NodeJs, resulting in apps that are 300mb+. The Marco macOS app is 3mb.
... 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.
Yes, there is a massive difference in runtime RAM usage.
> 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.
> If cross-platform sync and push notifications don't matter to you, Apple Mail and Thunderbird are good options.
Cross-platform sync and push notifications are literally part of IMAP.
> 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.
> Yes, there is a massive difference in runtime RAM usage.
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 :)
Totally agree with you. I take the post being mainly self-promotion with the hook of being "non-electron" for the HN crowd. They still like writing in 1 language and not worry about platforms, just not using the thing called electron.
When you're a team of two, writing in one language is a practical choice, not a philosophical one.
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.
I'm also in a team of 2 and still pick the best language for the task. It depends on the person, that's all.
[dead]
You seem to be chatting down some perceived tangental competition in order to chat yourself up. That kind of self-promotion's no good. Especially when picking ethereal "your writing sounds weird" ad homineming a decently detailed, reasonably hard-hitting, article.
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.
Forward Email is not a competitor of ours, they offer a completely different kind of product.
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.
What's left to conquer in email land?
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.
Turning your email newsletter into structured data. A db of events you get emailed, articles you should read, discounted to review, etc
Something I’d die for someone to tackle.
There’s still a huge opportunity for AI. The way it’s used currently (sorting & drafting replies) is barely scratching the surface. Until you can literally turn your mailbox over to AI the way you would with a human assistant, email UX is not a solved problem.
I'm far from an expert but I would say there will always be people who hate the current enshitified solutions and are looking for the new cool kid in town
> Email works perfectly
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....
They mean it works perfectly for them.
If I get Quantum Leaped back into my younger self, I'll start working on fixing email around 1993.
>How can someone say this in the age of AI spam.
The article is AI spam
We’ve worked on email infrastructure for multiple clients at Axon, and everything in this write-up checks out. Most startups just build wrappers around Postfix or SES and call it innovation. The hard problems, such as spam filtering, deliverability, and auth protocols, never get touched. That’s why 80% fail.
This is a weird article. Email is a hodgepodge of terrible protocols that have progressively had more and more technical debt laid upon them for decades and decades. Vendor quirks are everywhere, and it’s incredibly unreliable. Its defining quality – it’s decentralisation – has been beaten out of it by IP reputation so everybody ends up sending through a handful of providers.
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?
> Email is a hodgepodge of terrible protocols that have progressively had more and more technical debt laid upon them for decades and decades.
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.
> May I know what is so "terrible" about those protocols ans what "technical debt" are you talking about?
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.
> POP is pretty archaic and lack support for multiple clients accessing the same account.
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.
> incredibly unreliable
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.
To what lever can one apply money to get better spam filtering with even remotely constant returns to scale?
> and it’s incredibly unreliable
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.
It’s AI slop
> Quantum-Safe Email Security: Forward Email is the world's first and only email service to use quantum-resistant and individually encrypted SQLite mailboxes
lol thanks but no thanks
If 1 in 5 takes off, is that really a bad success rate given that's widely considered the average startup success rate?
Average startup success rate is 1/10 at best. The "90% of startups fail" metric that's often cited is likely inflated by B2B companies which find significantly more success (like, an order of magnitude more) than B2C.
Not sure that's inflated, as it's comparable to the 5-year failure rate of new storefront businesses, according to what I read in the pre-internet days.
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.
I wouldn't say Sparrow failed -- it got bought because it was successful. Did it reach its full potential? Certainly not. But certainly Google determined that it potentially could or it wouldn't have spent $MM to kill it.
> Email Statistics: 347.3 billion emails sent daily without major issues, serving 4.37 billion email users worldwide as of 2023.
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 :-)
50% of that is spam that is blocked. At least 50% of the rest is spamish but not spam spam.
So don't feel too overwhelmed!
But is it spam spam spam spam?
I'm guessing for most people 80-85 of those 86 are caught by a spam filter and are never seen.
Long article, but the fundamental premise is that IMAP, SMTP, and POP are all you need. And that email clients are good... This is just false IMHO. There is a reason why both Fastmail and Gmail implement their own protocols in addition to those.
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.
> A single message often needs to be in several different folders simultaneously.
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.
> 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.
Can you elaborate? Anything I can read on this?
https://developers.google.com/workspace/gmail/api/guides/syn...
>A single message often needs to be in several different folders simultaneously
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!
This again is a limitation of mapping labels to IMAP, which does not understand labels.
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.
>But they ignore the fundamental reality: email works perfectly for what it was designed to do.
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.
Actually recent email innovation I enjoyed is Mimestream, the macOS native client for Gmail. Apple’s smart inbox is half baked but better than nothing. Cloudflare now also has a pretty good email forwarding service.
Is 80% even that high? I thought the idea behind VC was to fund companies where 90% are doomed to fail, 9% might do okay, in order to cash in big on the 1% that have stellar success.
Am I way off with my numbers there?
My god this "article" is an inconsistent pile of AI slop. It actively contridicts itself and changes the thesis several times as it goes on and on and on.
That's crazy, is it really that hard? 37Signals can apparently do it and they are a tiny shop
> Gmail's threading: Enhanced email organization
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.
Not sure why they attack Fastmail and JMAP all the time.
That text reads weird. It is actually continuous text but randomly changes to headlines and inline notes and graphics.
I fell in love with Zenbe back in 2009 and i’m still angry at Facebook for acquishutting them down in 2010
> The Acquisition-to-Shutdown Pipeline
For the founders and their investors, that’s nut a bug it’s a feature
My heart goes out to those founders.
I think they need one of those star studded benefit concerts for them (oh, wait. It just occurred in Venice last weekend)
compared to other businesses this number seems OK :-)
Pretty sure this is AI written, hence the inconsistencies mentioned in this comment section.
Yet somehow ranked on this site, made it to my inbox, and was intriguing enfough for me to read until they end. Something that’s maybe true for 5% of the articles I get sent (which composes the top 30 HN articles of the previous 24 hours).
There’s a perverse lesson there.
It definitely is. Click the links that go to HN comments, in the section about how the community is right. Not one of them is anything to do with email.
Yes. I’d rather read the prompt than this.
This article makes some interesting points, but is clearly click bait (and written, gasp, a email company)
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?
While it may be true most email startups fail, rolling over and saying the UI has been solved is a bit defeatist IMO. Does the author even know about hey.com?
[dead]
[dead]
[dead]