Why email startups fail

Original Article ↗ Hacker News Discussion ↗

Reinventing Email vs “Email Works”

  • Some argue email “does its job” and attempts to “reinvent” it inevitably break core expectations.
  • Others point to products like HEY, Fastmail, Mimestream, etc. as evidence that UX and protocol-level innovation are still happening.
  • Several note that much of the startup activity is UI on top of existing infrastructure (IMAP/SMTP/SES wrappers), not new servers or protocols.

Marketing Email, Spam, and “Bacn”

  • Long subthread on whether “email marketing companies” are just spammers.
  • One side: anything mildly annoying or unsolicited is effectively spam; unsubscribe links don’t legitimize it and often don’t work well.
  • Other side: spam is defined by illegitimate address acquisition and ignoring opt-outs; opt‑in newsletters and promotions can be genuinely useful.
  • “Bacn” is mentioned as a tolerated middle ground: mail you technically asked for but mostly don’t want.

Market Saturation and Startup Success Rates

  • Many large players already dominate (Salesforce/ExactTarget, Oracle, Adobe, SendGrid/Twilio, Amazon SES, Mailchimp, etc.), leaving little room to scale new entrants.
  • Multiple commenters say a ~20% “exit” rate is actually good compared to typical startup failure rates; the article’s framing of 80% failure as shocking is disputed.
  • Acqui‑shutdowns are framed by some as normal, even desirable, outcomes for founders and investors.

Protocols, Reliability, and Self‑Hosting

  • Disagreement on whether email protocols are “a terrible hodgepodge” or elegant and resilient.
  • Critics cite POP’s limitations, IMAP complexity, SPF/DKIM/DMARC bolt‑ons, and opaque spam filtering.
  • Defenders say SMTP/IMAP are simple, robust, and that delivery issues mostly stem from big providers’ spam policies, not protocol design.
  • Several report self‑hosting experiences: some say it’s straightforward with proper DNS/auth setup; others say deliverability is fragile and hard.

UI, Clients, and Performance (Electron Debate)

  • The article’s “Electron Performance Crisis” claim triggers debate:
    • One side: users don’t care about RAM; Slack/Discord prove bloat doesn’t kill adoption.
    • Other side: many real users do notice and resent slow, resource‑hungry apps, but are locked in by network effects or corporate mandates (Teams/Slack).

Labels, Threads, and JMAP

  • Some argue classic IMAP/POP “folder” semantics are inadequate; modern workflows need labels/tags and robust threading (as in Gmail/Fastmail/Proton).
  • Others counter that IMAP already supports user flags and that threading can be done at the client level.
  • JMAP is defended as the only open protocol with first‑class label support, though adoption is low; the article’s negativity toward it and Fastmail is questioned.

Skepticism About the Article Itself

  • Several commenters suspect the post is AI‑generated or at least heavily AI‑assisted, citing odd structure, inconsistencies, irrelevant HN links, and shifting thesis.
  • Some see it as clickbait or self‑serving marketing from an email company, rather than a neutral analysis.

Remaining Opportunities

  • Suggested gaps:
    • Truly cross‑platform, offline‑first IMAP clients that aren’t Electron.
    • Smarter AI assistants that can fully manage inboxes, not just sort/draft.
    • Converting newsletters and transactional mail into structured, queryable data.
  • Others think new “cool kid” providers can still win by being less “enshittified” than incumbents.