Der Friedhof der E-Mail-Startups: Warum die meisten E-Mail-Startups scheitern

 (forwardemail.net)
2 Punkte von GN⁺ 2025-08-25 | Noch keine Kommentare. | Auf WhatsApp teilen

Matrix des Scheiterns von E-Mail-Startups

  • Viele E-Mail-Startups setzten lediglich eine einfache UI auf bestehende Infrastruktur wie Amazon SES oder Postfix auf.
  • Skiff, Sparrow, Email Copilot, ReplySend, Nveloped, Jumble und InboxFever sind alle gescheitert oder wurden nach einer Übernahme eingestellt.
  • Die meisten von YC und Techstars hervorgebrachten E-Mail-Startups pivotierten oder wurden frühzeitig eingestellt.
  • Dienste, die keine eigene Infrastruktur aufbauen konnten, überlebten nur kurzfristig.

Realitätscheck der Infrastruktur

  • Die meisten E-Mail-Startups entwickelten keine tatsächlichen Server, sondern nur Apps oder Clients.
  • Erfolgreiche Unternehmen boten SMTP-APIs und Zustellinfrastruktur wie SendGrid, Mailgun, Postmark an.
  • Erfolgreich war meist nicht der Versuch, Protokolle zu verändern, sondern bestehende Workflows zu verbessern.

Warum die meisten E-Mail-Startups scheitern

  • 1. Das Protokoll funktioniert gut, aber die Implementierung ist schwierig

    • SMTP, IMAP und POP3 sind seit Jahrzehnten erprobt.
    • Das Problem ist nicht ein neues Protokoll, sondern die Qualität der Implementierung.

  • 2. Netzwerkeffekte sind absolut

    • E-Mail wird von mehr als 4 Milliarden Menschen genutzt und ist mit allen Plattformen kompatibel.
    • Die Wechselkosten sind hoch, weshalb ein Umstieg auf andere Dienste schwierig ist.

  • 3. Es wird das falsche Problem adressiert

    • „E-Mail ist komplex“, „AI wird gebraucht“, „Sicherheit ist schwach“ – das sind falsche Annahmen.
    • Die tatsächlich wichtigen Probleme sind Zustellstabilität, Spam-Filterung und Entwickler-Tools.

  • 4. Die technische Schuld ist groß

    • Der Betrieb von SMTP-Servern, der Umgang mit Spam, Massenspeicher sowie Authentifizierungs- und Zustellinfrastruktur sind alle schwer aufzubauen.

  • 5. Die Infrastruktur existiert bereits

    • Mit Amazon SES, Postfix, Dovecot, SpamAssassin und anderen gibt es reichlich Open-Source- und kommerzielle Infrastruktur.

Fallstudien zum Scheitern von E-Mail-Startups

  • Fall Skiff

    • Als „Privacy-first E-Mail- und Produktivitätsplattform“ positioniert, konnte das Unternehmen beträchtliches Venture-Capital einwerben.
    • Im Februar 2024 übernahm Notion Skiff und versprach Integration sowie kontinuierliche Weiterentwicklung.
    • Tatsächlich wurde der Dienst nur wenige Monate nach der Übernahme sofort eingestellt, und die Gründer verließen Notion, um zu Cursor zu wechseln.
    • Tausende Nutzer wurden zu einer erzwungenen Migration gezwungen.

  • Analyse nach Accelerator

    • Y Combinator: E-Mail-App-Fabrik

      • Emailio (2014): mobiler E-Mail-Client → Pivot in Richtung Wellness
      • MailTime (2016): chatartiges E-Mail-System → Pivot zu einem Analysedienst
      • reMail (2009): E-Mail-Suche fürs iPhone → von Google übernommen und danach eingestellt
      • Rapportive (2012): soziale Gmail-Profile → von LinkedIn übernommen und danach eingestellt
      • Erfolgsquote: Es gab einige erfolgreiche Übernahmen (reMail, Rapportive), doch viele endeten mit einem Pivot oder als Acqui-hire.

    • Techstars: E-Mail-Friedhof

      • Email Copilot (2012): nach Übernahme eingestellt
      • ReplySend (2012): kompletter Fehlschlag
      • Nveloped (2012): „Easy. Secure. Email“ → gescheitert
      • Jumble (2015): E-Mail-Verschlüsselungsdienst → gescheitert
      • InboxFever (2011): E-Mail-API → gescheitert
      • Muster: vages Nutzenversprechen, fehlende echte technische Innovation, schnelles Scheitern

  • Die Falle des Venture Capital

    • VC Funding Paradox: E-Mail-Startups wirken einfach, sind in Wirklichkeit aber nahezu unmöglich.
    • Schon die Prämisse, mit der Investoren angelockt werden, ist so aufgebaut, dass sie Scheitern begünstigt.
    • Realität: E-Mail-Infrastruktur und -Protokolle sind bereits robust; es ist für neue Startups unmöglich, sie zu ersetzen.

Die technische Realität des modernen E-Mail-Stacks

  • Die meisten E-Mail-Startups bauen keine eigene Infrastruktur neu auf, sondern setzen Client-Anwendungen auf bestehende E-Mail-Server und -Protokolle auf.

  • Dadurch treten grundlegende Einschränkungen und Leistungsprobleme immer wieder auf und bilden eine wichtige Ursache für das Scheitern dieser Startups.

  • Überhöhter Speicherverbrauch (Memory Bloat)

    • Moderne E-Mail-Clients werden meist als Electron-basierte Web-Apps gebaut und verbrauchen übermäßig viel RAM.
    • Mailspring: bereits für grundlegende E-Mail-Funktionen 500MB+ Speicherverbrauch
    • Nylas Mail: vor der Einstellung 1GB+ Speicherverbrauch
    • Postbox: selbst im Leerlauf 300MB+ belegt
    • Canary Mail: häufige Abstürze aufgrund von Speicherproblemen
    • Thunderbird: Berichte über Nutzung von bis zu 90 % des Systemspeichers
    • Electron-Leistungskrise:
      • Cross-Platform-Frameworks wie Electron und React Native sind für Entwickler praktisch, nutzen Ressourcen aber ineffizient.
      • Das führt dazu, dass selbst einfache E-Mail-Funktionen Hunderte MB bis mehrere GB an Speicher verschlingen.

  • Akkuverbrauch (Battery Drain)

    • Durch ineffizienten Code und ineffiziente Arbeitsweisen ist der Akkuverbrauch auf Mobilgeräten und Laptops erheblich.
    • Hintergrundprozesse bleiben dauerhaft aktiv.
    • Unnötige API-Aufrufe erfolgen alle paar Sekunden.
    • Das Verbindungsmanagement ist ineffizient.
    • Selbst ohne unnötige Drittanbieter-Abhängigkeiten jenseits der Kernfunktionen ist die Ressourcenverschwendung erheblich.

Übernahmemuster: Erfolg vs. Misserfolg

  • Zwei Muster

    • Client-App-Muster (meist erfolglos)
      • E-Mail-Client-Anwendungen werden nach einer Übernahme in der Regel schnell eingestellt.
      • Sie werben zwar mit einer neuen User Experience, können aber weder die Infrastrukturabhängigkeit noch die Hürden der Netzwerkeffekte überwinden und sind daher nicht nachhaltig.
    • Infrastrukturmuster (oft erfolgreich)
      • Unternehmen, die zentrale E-Mail-Infrastruktur wie SMTP oder APIs bereitstellen, wachsen nach einer Übernahme oft weiter oder werden erfolgreich in Plattformen integriert.

  • Jüngste Beispiele

    • Scheitern von Client-Apps

      • Mailbox → Dropbox → Shutdown (2013–2015)
      • Sparrow → Google → Shutdown (2012–2013)
      • reMail → Google → Shutdown (2010–2011)
      • Skiff → Notion → Shutdown (2024)

    • Ausnahmehafter Erfolg

      • Superhuman → Grammarly (2025)
        • Ein erfolgreicher Übernahmefall durch strategische Integration; im Bereich der E-Mail-Clients ein seltener erfolgreicher Exit.

    • Erfolg bei Infrastruktur

      • SendGrid → Twilio (2019): Übernahme im Volumen von 3 Milliarden Dollar, danach weiter gewachsen
      • Mailgun → Sinch (2021): durch strategische Übernahme integriert
      • Postmark → ActiveCampaign (2022): trug zur Erweiterung der Plattformfunktionen bei
  • Während Client-Apps nach Übernahmen oft im Shutdown enden, zeigt sich deutlich die Tendenz, dass Infrastruktur-Anbieter auch nach Übernahmen überleben und zu Kernelementen von Plattformen werden.

Entwicklung und Konsolidierung der Branche

  • Natürliche Branchenentwicklung

    • Die E-Mail-Branche hat sich im Lauf der Zeit in einer Form entwickelt, bei der große Unternehmen kleinere Firmen übernehmen, um Funktionen zu integrieren oder Wettbewerb auszuschalten.
    • Das ist nicht nur ein negatives Phänomen, sondern ein natürlicher Entwicklungsprozess, wie er in den meisten reifen Branchen zu beobachten ist.

  • Veränderungen nach Übernahmen

    Wenn E-Mail-Unternehmen übernommen werden, erleben Nutzer typischerweise folgende Veränderungen:
    • Service-Migration: Konten und Daten müssen auf eine neue Plattform übertragen werden.
    • Funktionsänderungen: Spezialisierte Funktionen verschwinden oder werden in anderer Form ersetzt.
    • Preisanpassungen: Abomodelle und Tarife können sich ändern.
    • Unannehmlichkeiten während der Integration: Während der Service-Integration kann es zu vorübergehenden Störungen oder Unterbrechungen kommen.

  • Was Nutzer in der Übergangsphase beachten sollten

    Reaktionsmöglichkeiten für Nutzer in einer Phase der Branchenkonsolidierung:
    • Alternative Dienste prüfen: andere Anbieter mit ähnlichen Funktionen erkunden
    • Migrationspfade verstehen: Die meisten Dienste bieten Export-Tools an, die genutzt werden sollten.
    • Langfristige Stabilität berücksichtigen: Es ist vorteilhaft, Anbieter zu wählen, die seit Langem am Markt sind und als zuverlässig gelten.

Realitätscheck auf Hacker News

Alle E-Mail-Startups erhalten auf Hacker News immer wieder dasselbe Feedback:

Der aktuelle Boom der AI-E-Mail-Startups

  • Die jüngste Welle

    2024 entstand eine neue Welle von Startups rund um "AI-basierte E-Mail", und bereits die erste größere erfolgreiche Übernahme hat stattgefunden:
    • Superhuman: insgesamt 33 Millionen US-Dollar Finanzierung, 2025 von Grammarly übernommen — eine Client-App-Übernahme, die als seltener Erfolg gilt
    • Shortwave: ein Wrapper auf Basis von Gmail mit AI-Zusammenfassungen
    • SaneBox: AI-basierte E-Mail-Filterung, die tatsächlich funktioniert, aber nicht revolutionär ist

  • Die weiterhin bestehenden Probleme

    Auch mit dem Label "AI" werden die grundlegenden Probleme von E-Mail nicht gelöst:
    • AI-Zusammenfassungen: Die meisten E-Mails sind bereits kurz und knapp
    • Intelligente Antworten: Gmail bietet das bereits seit Jahren an
    • Geplantes Senden von E-Mails: Outlook unterstützt das standardmäßig
    • Prioritätserkennung: In bestehenden E-Mail-Clients gibt es bereits effektive Filtersysteme
      Die harte Realität: AI-Funktionen sind keine grundlegende Lösung, weil sie in der Praxis gewaltige Infrastrukturinvestitionen erfordern, obwohl sie nur vergleichsweise kleine Unannehmlichkeiten lösen

Tatsächlich erfolgreiche Beispiele im E-Mail-Bereich

  • Infrastrukturunternehmen (erfolgreiche Fälle)

  • E-Mail-Dienstanbieter (die Überlebenden)

    • FastMail: seit über 25 Jahren in Betrieb, profitables unabhängiges Unternehmen
      • Kontroverse um die JMAP-Investitionen: Fastmail investierte Ressourcen in das JMAP-Protokoll, das auch nach mehr als zehn Jahren nur wenig Verbreitung gefunden hat, und lehnte zugleich die von vielen Nutzern gewünschte PGP-Verschlüsselung ab. Das wird als strategische Entscheidung bewertet, Protokollinnovation höher zu priorisieren als Nutzeranforderungen. Die meisten E-Mail-Clients sind weiterhin auf IMAP/SMTP angewiesen
    • ProtonMail: auf Datenschutz fokussiert, mit nachhaltigem Wachstum
    • Zoho Mail: als Teil einer großen Business-Produkt-Suite stabil betrieben
    • Forward Email(We): seit über 7 Jahren in Betrieb und zugleich profitabel und wachsend
    • Erfolgsfall im Unternehmensbereich: Forward Email unterstützt eine E-Mail-Lösung für 30.000 Alumni der Universität Cambridge und ermöglicht so Einsparungen von 87.000 US-Dollar pro Jahr
    • Muster: Diese Anbieter ersetzen E-Mail nicht, sondern stärken sie.

  • Außergewöhnlicher Erfolgsfall: Xobni

    Xobni war ein selten erfolgreiches Startup, weil es die bestehende E-Mail-Umgebung verbessert hat.
    • Die richtige Strategie:
      • Auf bestehender E-Mail aufgebaut: Integration mit Outlook
      • Reale Probleme gelöst: Kontaktmanagement und E-Mail-Suche verbessert
      • Integrationsorientiert: Funktionierte innerhalb bestehender Workflows
      • Enterprise-Fokus: Zielmarkt waren Unternehmen, die für Produktivitätssteigerung bezahlen
    • Ergebnis: 2013 von Yahoo für 60 Millionen US-Dollar übernommen und bot Investoren eine nennenswerte Rendite.
    • Spätere Erfolge der Gründer:
      • Matt Brezina: aktiver Angel-Investor, investierte in Dropbox, Mailbox und andere
      • Adam Smith: gründete weiterhin erfolgreich Unternehmen im Produktivitätsbereich
      • Beide Gründer bewiesen, dass "Erfolg bei E-Mail nicht durch Ersatz, sondern durch Verbesserung entsteht"

  • Erfolgsmuster

    Die Gemeinsamkeiten erfolgreicher Unternehmen im E-Mail-Bereich:
    • 1. Infrastruktur aufbauen → SendGrid, Mailgun
    • 2. Bestehende Workflows stärken → Xobni, FastMail
    • 3. Auf Zuverlässigkeit fokussieren → Amazon SES, Postmark
    • 4. Entwickler unterstützen → APIs und Tools bereitstellen, keine Endnutzer-Apps

Gibt es Beispiele dafür, dass E-Mail erfolgreich neu erfunden wurde?

Diese Frage ist wichtig, weil sie das Wesen von Innovation bei E-Mail auslotet.
Die kurze Antwort lautet: Niemandem ist es gelungen, E-Mail zu ersetzen, aber es gibt erfolgreiche Fälle, in denen E-Mail ‚gestärkt‘ wurde.

  • Innovationen, die sich tatsächlich durchgesetzt haben

    Die Innovationen, die sich in den vergangenen 20 Jahren bei E-Mail etabliert haben, haben allesamt die bestehenden Protokolle nicht ersetzt, sondern gestärkt:

  • Tools, die E-Mail ergänzen statt ersetzen

    • Slack: ein Team-Chat-Tool, verschickt aber weiterhin E-Mail-Benachrichtigungen
    • Discord: eine Community-zentrierte Plattform, deren Kontoverwaltung aber auf E-Mail basiert
    • WhatsApp: für Messaging optimiert, doch Unternehmen nutzen weiterhin E-Mail
    • Zoom: ein unverzichtbares Tool für Videokonferenzen, aber Meeting-Einladungen werden per E-Mail verschickt

  • Das HEY-Experiment

    HEY von Basecamp war zuletzt der ernsthafteste Versuch, E-Mail „neu zu erfinden“.
    • Launch: 2020, begleitet von massiver PR
    • Ansatz: ein neues E-Mail-Paradigma mit Screening, Bundling und Workflows
    • Reaktion: Einige waren begeistert, die Mehrheit blieb jedoch bei der bestehenden E-Mail-Nutzung
    • Realität: Letztlich war es weiterhin nur eine neue Oberfläche für SMTP/IMAP-basierte E-Mail
    • Empirisches Beispiel: Gründer DHH nutzt seit Jahren Forward Email auf seiner persönlichen Domain dhh.dk. Das zeigt, dass selbst E-Mail-Innovatoren auf bewährte Infrastruktur angewiesen sind.

  • Was tatsächlich funktioniert

    Die erfolgreichsten E-Mail-Innovationen sind:
    • 1. Bessere Infrastruktur: schnellere Server, verbesserte Spam-Filterung, höhere Zustellraten
    • 2. Verbesserte Interfaces: Gmails Konversationsansicht, Outlooks Kalender-Integration
    • 3. Entwickler-Tools: APIs zum E-Mail-Versand, Webhooks für Tracking
    • 4. Spezialisierte Workflows: CRM-Integrationen, Marketing-Automatisierung, transaktionale E-Mails

Fazit: Bis heute hat keine Innovation E-Mail ersetzt; erfolgreich waren sie alle in der Richtung, E-Mail besser zu machen

Aufbau moderner Infrastruktur für bestehende E-Mail-Protokolle: unser Ansatz bei Forward Email

Bevor wir auf gescheiterte Beispiele eingehen, ist es wichtig zu verstehen, was bei E-Mail tatsächlich funktioniert
Nicht E-Mail selbst ist kaputt, sondern viele Unternehmen verursachen Probleme, indem sie versuchen, ein bereits gut funktionierendes System zu „reparieren“

  • Das Spektrum der E-Mail-Innovation

    E-Mail-Innovation lässt sich grob in drei Kategorien einteilen:
    • 1. Protokoll-Verbesserung: Standards wie SMTP, IMAP und POP3 stabiler und schneller implementieren
    • 2. Workflow-Optimierung: Tools und Funktionen, die bestehende E-Mail-Abläufe effizienter machen
    • 3. UI/UX-Innovation: bessere Zugänglichkeit und Nutzbarkeit durch neue Interfaces

  • Warum wir uns auf Infrastruktur konzentrieren

    Statt eine neue App zu bauen, haben wir uns entschieden, moderne E-Mail-Infrastruktur aufzubauen. Die Gründe dafür sind:
    • Bewährte E-Mail-Protokolle: SMTP funktioniert seit 1982 zuverlässig
    • Das Problem ist die Qualität der Implementierung: Viele E-Mail-Dienste nutzen noch immer veraltete Software-Stacks
    • Was Nutzer wollen = Zuverlässigkeit: keine neuen Features, sondern stabile Workflows, die nicht kaputtgehen
    • Bedarf bei Entwicklern: bessere APIs und Verwaltungsoberflächen werden benötigt

  • Was bei E-Mail tatsächlich funktioniert

    Das erfolgreiche Muster ist einfach: bestehende E-Mail-Workflows nicht ersetzen, sondern stärken
    • Aufbau schnellerer und zuverlässigerer SMTP-Server
    • bessere Spam-Filterung, ohne legitime E-Mails zu stören
    • Bereitstellung entwicklerfreundlicher APIs, die bestehende Protokolle nutzen können
    • Verbesserung der Zustellrate durch die richtige Infrastruktur
      Fazit: Innovation bei E-Mail bedeutet nicht „Ersatz“, sondern, das bestehende System durch Infrastruktur besser zu machen

Unser Ansatz: Warum Forward Email anders ist

  • Was wir tun (What We Do)

    • Reale Infrastruktur aufbauen: SMTP/IMAP-Server von Grund auf selbst entwickeln
    • Fokus auf Zuverlässigkeit: 99,99 % Uptime und korrektes Error-Handling
    • Bestehende Workflows stärken: kompatibel mit allen E-Mail-Clients und zuverlässig im Betrieb
    • Unterstützung für Entwickler: APIs und Tools bereitstellen, die tatsächlich nutzbar sind
    • Vollständige Kompatibilität wahren: vollständige Einhaltung der Standards SMTP / IMAP / POP3

  • Was wir nicht tun (What We Don’t Do)

    • Entwicklung eines neuen E-Mail-Clients im Namen der „Innovation“
    • Versuch, bestehende E-Mail-Protokolle zu ersetzen
    • Hinzufügen unnötiger AI-Funktionen
    • unrealistische Versprechen, E-Mail „reparieren“ zu wollen
      Im Kern geht es darum, Zuverlässigkeit und Kompatibilität auf bewährten Protokollen zu erhöhen, und sich statt auf Show-Innovation auf Infrastruktur zu konzentrieren, die tatsächlich funktioniert.

Wie wir eine tatsächlich funktionierende E-Mail-Infrastruktur aufgebaut haben

  • Unser Anti-Startup-Ansatz (Our Anti-Startup Approach)

    Während andere Unternehmen Millionen von Dollar verbrannten, um E-Mail neu zu erfinden, haben wir uns einfach auf den Aufbau zuverlässiger Infrastruktur konzentriert:
    • Kein Pivot: Seit über 7 Jahren ausschließlich auf E-Mail-Infrastruktur fokussiert
    • Keine Exit-Strategie durch Übernahme: Langfristiger Betrieb statt kurzfristigem Verkauf
    • Kein Innovations-Hype: E-Mail nicht „reparieren“, sondern dafür sorgen, dass sie besser funktioniert

  • Was uns unterscheidet (What Makes Us Different)

    • Erfüllung staatlicher Standards: Section 889 konform, mit institutionellen Kunden wie der United States Naval Academy
    • OpenPGP + OpenWKD-Unterstützung: Unterstützung für PGP-Verschlüsselung, die Fastmail abgelehnt hat, und damit echte Verschlüsselungsfunktionen, die Nutzer wollen
    • Differenzierter Technologie-Stack:
      • Der gesamte Stack ist in JavaScript entwickelt (im Gegensatz zu Postfix auf Basis von C-Code aus den 1980ern)
      • Kein Glue Code nötig dank einer einzigen Sprache
      • Web-native Architektur mit hoher Wartbarkeit
      • Keine Legacy-Schulden, moderne Codebasis
    • Privacy by Design:
      • E-Mails werden nicht auf Festplatten oder in Datenbanken gespeichert
      • Keine Speicherung von Metadaten, Logs oder IP-Adressen
      • Verarbeitung beim Weiterleiten ausschließlich im Arbeitsspeicher
    • Über das Technical Whitepaper und die Dokumentation werden Sicherheits- und Architekturdetails offengelegt

  • Warum wir Erfolg haben, wo andere scheitern (Why We Succeed Where Others Fail)

    • 1. Wir bauen Infrastruktur, keine App: Fokus auf Server und Protokolle
    • 2. Verbessern statt ersetzen: Kompatibilität mit bestehenden E-Mail-Clients bleibt erhalten
    • 3. Aus eigener Kraft profitabel: Nachhaltiger Betrieb ohne VC-Druck
    • 4. Tiefes technisches Verständnis: Mehr als 7 Jahre spezialisierte Erfahrung mit E-Mail
    • 5. Entwicklerzentriert: APIs und Tools, die bei der Lösung realer Probleme helfen

Die Sicherheitsherausforderungen der E-Mail-Infrastruktur

E-Mail-Sicherheit ist eine komplexe Herausforderung, mit der jeder Dienstanbieter konfrontiert ist.
Wichtiger als einzelne Vorfälle ist es, die gemeinsamen Sicherheitsaspekte zu verstehen, die überall gelöst werden müssen.

  • Gemeinsame Sicherheitsaspekte (Common Security Considerations)

    • Datenschutz: Schutz von Nutzerdaten und Kommunikation
    • Zugriffskontrolle: Authentifizierung und Rechteverwaltung
    • Infrastruktursicherheit: Absicherung von Servern und Datenbanken
    • Compliance: Einhaltung von Vorschriften wie GDPR und CCPA
    • Einsatz fortschrittlicher Verschlüsselung: Sicherheitsrichtlinie von Forward Email:
      • Mailbox-Verschlüsselung auf Basis von ChaCha20-Poly1305
      • Vollständige Festplattenverschlüsselung auf Basis von LUKS v2
      • Verschlüsselung im Speicher, bei der Übertragung und im Ruhezustand

  • Der Wert von Transparenz (The Value of Transparency)

    Im Fall eines Sicherheitsvorfalls sind Transparenz und schnelles Handeln die wichtigste Reaktion. Zu den Best Practices gehören:
    • Sofortige Offenlegung: Damit Nutzer die Situation verstehen und reagieren können
    • Detaillierte Zeitleiste: Zeigt Umfang des Problems und Stand des Verständnisses
    • Schnelle Gegenmaßnahmen: Belegt technische Handlungsfähigkeit
    • Geteilte Erkenntnisse: Trägt zur Verbesserung der Sicherheit in der gesamten Branche bei

  • Fortlaufende Sicherheitsherausforderungen (Ongoing Security Challenges)

    E-Mail-Sicherheit entwickelt sich ständig weiter, und in den folgenden Bereichen sind kontinuierliche Verbesserungen nötig:
    • Verschlüsselungsstandards: Einsatz moderner Verfahren wie TLS 1.3
    • Authentifizierungsprotokolle: Stärkung von DKIM, SPF und DMARC
    • Bedrohungserkennung: Bessere Spam- und Phishing-Filterung
    • Härtung der Infrastruktur: Mehr Sicherheit für Server und Datenbanken
    • Verwaltung der Domain-Reputation: Einführung von Blockierungsregeln zur Abwehr neuer Bedrohungen wie dem starken Anstieg von Spam über Microsoft-onmicrosoft.com-Adressen

Fazit: Konzentriere dich auf Infrastruktur, nicht auf Apps

  • Die Belege sind eindeutig (The Evidence Is Clear)

    Die Analyse von Hunderten E-Mail-Startups zeigt:
    • Ausfallquote von über 80 %: Die meisten E-Mail-Startups scheitern vollständig (die tatsächliche Zahl dürfte noch höher liegen)
    • Client-Apps scheitern meist: Übernahmen führen oft direkt zur Einstellung des Dienstes
    • Infrastruktur hat Erfolgschancen: Unternehmen, die SMTP/API-Dienste aufbauen, florieren häufig
    • Druck durch VC-Finanzierung: Venture-Kapital erzeugt unrealistischen Wachstumsdruck
    • Anhäufung technischer Schulden: Der Aufbau von E-Mail-Infrastruktur ist viel schwieriger als erwartet

  • Der historische Kontext (The Historical Context)

    In den vergangenen 20 Jahren haben Startups immer wieder das Ende der E-Mail vorhergesagt:
    • 2004: „Soziale Netzwerke werden E-Mail ersetzen“
    • 2008: „Mobiles Messaging wird E-Mail töten“
    • 2012: „Slack wird E-Mail ersetzen“
    • 2016: „AI wird E-Mail revolutionieren“
    • 2020: „Im Zeitalter der Remote-Arbeit braucht es neue Kommunikationstools“
    • 2024: „AI wird E-Mail endlich reparieren“
      Doch E-Mail existiert weiterhin, wächst und bleibt unverzichtbar.

  • Die eigentliche Lehre (The Real Lesson)

    Die Lehre ist nicht, dass E-Mail nicht verbessert werden kann, sondern dass der richtige Ansatz gewählt werden muss:
    • 1. E-Mail-Protokolle sind tragfähig: SMTP, IMAP und POP3 sind bewährte Standards
    • 2. Infrastruktur ist entscheidend: Zuverlässigkeit und Leistung sind wichtiger als auffällige Funktionen
    • 3. Verbessern statt ersetzen: Keine Konfrontation mit E-Mail, sondern Lösungen, die mit ihr zusammenarbeiten
    • 4. Nachhaltigkeit vor Wachstum: Profitabele Unternehmen überleben länger als das VC-getriebene Modell „schnell wachsen und kaputtmachen“
    • 5. Unterstützung für Entwickler: Tools und APIs für Entwickler schaffen mehr Wert als Endnutzer-Apps
    • Die zentrale Chance: Bereits bewährte Protokolle besser umzusetzen, statt neue Protokolle zu entwickeln
    • Vertiefende Analyse: 79 Best Email Services (2025)
  • Wenn du ein E-Mail-Startup gründen willst, solltest du erwägen, Infrastruktur statt Apps zu bauen.
    • Was die Welt braucht, sind nicht mehr E-Mail-Apps, sondern bessere E-Mail-Server.

Der erweiterte E-Mail-Friedhof: noch mehr Fehlschläge und Diensteinstellungen

  • Googles gescheiterte E-Mail-Experimente (Google's Email Experiments Gone Wrong)

    Obwohl Google Gmail besitzt, hat das Unternehmen mehrere E-Mail-Projekte eingestellt:
    • Google Wave (2009–2012): Wurde als „E-Mail-Killer“ bezeichnet, aber niemand verstand es
    • Google Buzz (2010–2011): Versuch einer sozialen E-Mail-Integration, gescheitert
    • Inbox by Gmail (2014–2019): Als „smarter“ Nachfolger von Gmail gestartet, am Ende jedoch eingestellt
    • Google+ (2011–2019): Versuch, E-Mail-Funktionen zu integrieren, gescheitert
    • Muster: Selbst Google mit Gmail konnte E-Mail nicht erfolgreich neu erfinden

  • Newton Mail und sein dreifacher Tod (The Serial Failure: Newton Mail's Three Deaths)

    Newton Mail starb ganze dreimal:
    • 1. CloudMagic (2013–2016): Früher E-Mail-Client, später von Newton übernommen
    • 2. Newton Mail (2016–2018): Marken-Relaunch, wegen gescheitertem Abo-Modell eingestellt
    • 3. Newton Mail Revival (2019–2020): Wiederbelebungsversuch, erneut gescheitert
    • Lehre: E-Mail-Clients können ein Abo-Modell nicht dauerhaft tragen

  • Apps, die nie gestartet sind (The Apps That Never Launched)

    Viele E-Mail-Startups verschwinden noch vor dem Launch:
    • Tempo (2014): Versuch einer Kalender-E-Mail-Integration, vor dem Start eingestellt
    • Mailstrom (2011): E-Mail-Management-Tool, vor dem Start übernommen
    • Fluent (2013): E-Mail-Client, Entwicklung eingestellt

  • Das Muster Übernahme und dann Abschaltung (The Acquisition-to-Shutdown Pattern)

    Mehrere E-Mail-Apps wurden kurz nach einer Übernahme eingestellt:

  • Konsolidierung der E-Mail-Infrastruktur (Email Infrastructure Consolidation)

    Auch im Infrastruktur-Bereich sind Konsolidierung und Abschaltungen häufig:

Der Open-Source-E-Mail-Friedhof: wenn „kostenlos“ nicht tragfähig ist

  • Nylas Mail → Mailspring: ein gescheiterter Fork

  • Eudora: ein 18 Jahre langer Todesmarsch

    • 1988–2006: Dominierender E-Mail-Client auf Mac und Windows
    • 2006: Qualcomm kündigt das Ende der Entwicklung an
    • 2007: Als „Eudora OSE“ Open Source gemacht
    • 2010: Projekt vollständig eingestellt
    • Lehre: Selbst erfolgreiche E-Mail-Clients verschwinden irgendwann

  • FairEmail: von den Google-Play-Richtlinien getötet

    • FairEmail: Datenschutzorientierter Android-E-Mail-Client
    • Google Play: Wegen „Richtlinienverstoß“ entfernt
    • Realität: Durch Plattformrichtlinien können E-Mail-Apps von einem Tag auf den anderen verschwinden

  • Das Wartungsproblem (The Maintenance Problem)

    Warum Open-Source-E-Mail-Projekte scheitern:
    • Komplexität: E-Mail-Protokolle korrekt zu implementieren ist schwierig
    • Sicherheit: Ständige Sicherheitsupdates sind nötig
    • Kompatibilität: Sie müssen mit allen E-Mail-Anbietern kompatibel sein
    • Ressourcenmangel: Ehrenamtliche Entwickler leiden unter Burnout

Der Boom der KI-E-Mail-Startups: Wiederholte Geschichte unter dem Namen „Intelligenz“

  • Der aktuelle KI-E-Mail-Goldrausch (2024)

  • Der Finanzierungsrausch

    • Allein 2024 investierten VCs über 100 Mio. US-Dollar
    • Das sich wiederholende Versprechen: „ein revolutionäres E-Mail-Erlebnis“
    • Das sich wiederholende Problem: Es wird nur auf bestehender Infrastruktur aufgebaut
    • Das sich wiederholende Ergebnis: Die meisten werden voraussichtlich innerhalb von 3 Jahren scheitern

  • Warum sie wieder scheitern werden

    • 1. KI versucht ein „Nicht-Problem“ von E-Mail zu lösen – E-Mail funktioniert bereits gut
    • 2. Gmail bietet bereits KI-Funktionen – Smart Reply, Priorisierter Posteingang, Spam-Filterung
    • 3. Datenschutzbedenken – KI muss alle E-Mails lesen
    • 4. Problematische Kostenstruktur – KI-Verarbeitung ist teuer, E-Mail ist im Kern ein Niedrigpreis-Dienst
    • 5. Netzwerkeffekte – Die dominante Stellung von Gmail/Outlook lässt sich nicht brechen

  • Das unvermeidliche Ergebnis

    • 2025: Superhuman → Übernahme durch Grammarly (seltener Erfolgsfall)
    • 2025–2026: Die meisten KI-E-Mail-Startups werden pivotieren oder schließen
    • 2027: Einige überlebende Unternehmen werden übernommen, aber mit gemischtem Erfolg
    • 2028: Es könnte ein neuer Hype wie „Blockchain-E-Mail“ auftauchen

Die Katastrophe der Konsolidierung: Wenn „Überlebende“ zur Katastrophe werden

  • Konsolidierung großer E-Mail-Dienste

    Die E-Mail-Branche hat sich stark konsolidiert

  • Outlook: Der „Überlebende“ mit nicht endenden Problemen

    Microsoft Outlook ist weiterhin Mainstream in der Branche, verursacht aber fortlaufend Probleme
    • Speicherlecks: mehrere GB RAM-Nutzung, häufige Neustarts erforderlich
    • Synchronisierungsprobleme: E-Mails verschwinden und tauchen dann wieder auf
    • Leistungsprobleme: langsamer Start, häufige Abstürze
    • Kompatibilitätsprobleme: Konflikte mit E-Mail-Anbietern von Drittanbietern

    Praxisbeispiel: Obwohl die Standard-IMAP-Implementierung eingehalten wird, geht Outlook häufig kaputt

  • Probleme mit der Postmark-Infrastruktur

    Probleme, die nach der Übernahme durch ActiveCampaign auftraten

  • Jüngste Todesfälle bei E-Mail-Clients (2024–2025)

    • Postbox → eM Client: direkt nach der Übernahme sofort eingestellt, erzwungene Migration der Nutzer
    • Canary Mail: trotz Unterstützung durch Sequoia massive Nutzerbeschwerden
    • Spark by Readdle: zunehmende Berichte über Qualitätsverlust
    • Mailbird: Lizenzprobleme und Verwirrung um Abonnements
    • Airmail: auf Sparrow-Code basierend, anhaltende Zuverlässigkeitsprobleme

  • Fälle von E-Mail-Erweiterungen/Dienstabschaltungen

  • E-Mail-Unternehmen, die tatsächlich überlebt haben

    • Mailmodo: aus YC, interaktive E-Mail-Kampagnen, 2 Mio. US-Dollar Finanzierung von Sequoia Surge
    • Mixmax: insgesamt 13,3 Mio. US-Dollar Finanzierung, weiterhin als Sales-Engagement-Plattform aktiv
    • Outreach.io: Bewertung von über 4,4 Mrd. US-Dollar, bereitet sich auf IPO vor
    • Apollo.io: 2023 mit 1,6 Mrd. US-Dollar bewertet, 100 Mio. US-Dollar Series D aufgenommen
    • GMass: auf Gmail-Erweiterung basierend, gebootstrapptes Erfolgsbeispiel mit 140.000 US-Dollar Monatsumsatz
    • Streak CRM: Gmail-basiertes CRM, seit 2012 stabil im Betrieb
    • ToutApp: 2017 erfolgreich von Marketo übernommen
    • Bananatag: 2021 von Staffbase übernommen, wird als „Staffbase Email“ weitergeführt

  • Das Kernmuster

    • Erfolgreiche Unternehmen ersetzen E-Mail nicht, sondern verbessern den Workflow
    • Sie haben Tools gebaut, die kooperativ mit der E-Mail-Infrastruktur arbeiten

Fazit

  • Mehr als 80 % der E-Mail-Startups scheitern
  • App-zentrierte Ansätze scheitern, infrastrukturzentrierte Ansätze sind erfolgreich
  • Zentrale Lehren:
    • 1. E-Mail-Protokolle funktionieren bereits gut
    • 2. Stabilität und Performance der Infrastruktur sind entscheidend
    • 3. Verstärken statt Ersetzen ist effektiver
    • 4. Ein nachhaltiges Geschäftsmodell ist notwendig
    • 5. Tools und APIs für Entwickler sind der Schlüssel zum Erfolg

Verwandte Beiträge

Noch keine Kommentare.

Noch keine Kommentare.