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.
I know nothing about the product, maybe it’s wonderful, but whoever prompted this webpage into existence needs their API key revoked. Whatever point they wanted to convey is drowning in the ridiculous overuse of bulleted lists, flow diagrams, tip blocks, headings with nothing to back them up, and incessant, needless hyperlinks. It’s kind of surreal to scroll through.
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.
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.
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.
> 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.
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.
> 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?
In any case, I do 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.
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 :)
> 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!
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”.
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.
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.
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.
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
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.
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.
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.
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.
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.
> 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.
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.
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.
I know nothing about the product, maybe it’s wonderful, but whoever prompted this webpage into existence needs their API key revoked. Whatever point they wanted to convey is drowning in the ridiculous overuse of bulleted lists, flow diagrams, tip blocks, headings with nothing to back them up, and incessant, needless hyperlinks. It’s kind of surreal to scroll through.
> 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 :-)
I'm guessing for most people 80-85 of those 86 are caught by a spam filter and are never seen.
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.
"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.
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.
Or the band you love is in town
> 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
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.
> 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?
> 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
This is indeed a really weird article, and seems to be partially generated from that I, as an actual human, wrote: https://marcoapp.io/blog/marco-an-introduction
In any case, I do 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
> 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.
> 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.
Pretty sure this is AI written, hence the inconsistencies mentioned in this comment section.
Yes. I’d rather read the prompt than this.
My first thought was wow - 20% of email startups succeed? That’s actually pretty good.
> 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!
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.
Obligatory “as far as the customer is concerned, the interface is the product”
UX is what made the difference between the first iPhone and a palm.
We have regressed as a society.
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 :)
> 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....
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.
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.
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.
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
> 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.
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?
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.
> 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
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.
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.
> 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.
I fell in love with Zenbe back in 2009 and i’m still angry at Facebook for acquishutting them down in 2010
>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.
Not sure why they attack Fastmail and JMAP all the time.
compared to other businesses this number seems OK :-)
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.
> The Acquisition-to-Shutdown Pipeline
For the founders and their investors, that’s nut a bug it’s a feature
[dead]
[dead]