Ein Trello-Klon ist nicht Trello. Er hat nicht Trellos Berechtigungssystem, keine Enterprise-Kontrollen, keine mobilen Apps, keine Benachrichtigungseinstellungen, Automatisierungen, Integrationen, Vorlagen oder Admin-Oberflächen, keinen Marketplace, kein Support-Team, keine Verfügbarkeitszusagen, keine Abrechnungsinfrastruktur und nicht fünfzehn Jahre Produktentscheidungen, die in kleinen Ecken der Oberfläche versteckt sind. Aber er kann Spalten haben, Karten, Drag and Drop, lokalen Zustand und einen Export-Button. Für viele persönliche Arbeitsabläufe reicht das. Und „reicht“ ist der Teil, der SaaS Sorgen machen sollte.
Dasselbe gilt für Schreibwerkzeuge. Ein rewritable-Dokument ist nicht Microsoft Word. Es bildet nicht den ganzen Office-Stack nach und auch keine Enterprise-Zusammenarbeit, keine Änderungsverfolgung, keine Vorlagenbibliotheken, keine Kompatibilitätsmodi, keine Richtlinienkontrollen und nicht jahrzehntelang angesammelte Dokumenten-Seltsamkeiten. Aber es kann eine Schreibfläche sein, seine eigenen Daten mitführen, seine eigene Bearbeitungsoberfläche anbieten und sich auf Zuruf selbst ändern. Wieder: Es reicht.
Das ist die eigentliche Verschiebung. Nicht, dass eine einzelne Person Trello nachbauen kann. Nicht, dass ein lokales Dokument Word ersetzt. Die Verschiebung besteht darin, dass sich der nützliche Teil eines Softwareprodukts jetzt vom Produkt drumherum trennen lässt. Der Arbeitsablauf muss nicht mehr im Paket mit einem Konto, einem Anbieter, einer Preisseite, einer Roadmap und dem Speicher von jemand anderem kommen.
Nutzer ersetzen SaaS nicht in Bausch und Bogen
Die aktuelle Welle selbstgebauter Software ist real. Es sind längst nicht mehr nur Entwickler, die eine bessere Autovervollständigung nutzen. Lovable gibt an, dass sich vier von fünf seiner Nutzer nicht technischen Rollen zuordnen. Gründer, Freelancer, Produktleute, Operations-Teams, Marketer, Berater, Verkäufer, Designer und Mitarbeiter aus Finanzen oder Administration bauen direkt Software. Business Insider berichtete, dass Lovable die Marke von 500 Millionen Dollar an jährlich wiederkehrendem Umsatz überschritten hat und dass die meisten Nutzer keinen Engineering-Hintergrund haben.
Das ist kein kleines Signal. Softwareentwicklung rückt näher an die Leute, die das Problem im Arbeitsablauf tatsächlich spüren. Aber man überschätzt leicht, was daraus folgt.
Dass Nutzer mehr Software bauen, heißt nicht, dass sie SaaS in dem Sinn ersetzen, den die meisten damit meinen. Sie bauen nicht nebenbei Salesforce, Workday, SAP, ServiceNow, Microsoft 365 oder Snowflake mit ein paar Prompts und einem Wochenende voller Begeisterung nach. Die Systeme, auf denen große Unternehmen laufen, sind nicht bloß Masken und Formulare. Sie sind Berechtigungen, Integrationen, Compliance, Audit Trails, Supportverpflichtungen, gemeinsame Datenmodelle, Beschaffungshistorien, Migrationspfade und Risikotransfer.
Nutzer bauen mehr Software
Gerade weil Nutzer überhaupt mehr Software bauen, wurde die Klarna-Geschichte zu einer so schlechten Abkürzung. Die vereinfachte Fassung lautete, Klarna habe Salesforce und Workday abgeschafft und SaaS durch KI ersetzt. Klarna hat aber etwas anderes getan. Das Unternehmen hat Teile seines SaaS-Stacks verkleinert und umgebaut, und selbst sein CEO widersprach später der Vorstellung, andere Unternehmen sollten das als allgemeines Rezept lesen, um Salesforce durch KI zu ersetzen.
Dasselbe Muster zeigt sich überall in der Geschichte vom Selberbauen. Ersetzt wird zuerst dort, wo das Werkzeug klein, lokal, persönlich, intern oder so lästig ist, dass „gut genug“ gegen „vollständig“ gewinnt.
Ein privates Aufgaben-Board. Ein einfacher Projekt-Tracker. Ein schlankes CRM für einen einzigen Vertriebsprozess. Ein Dashboard für einen wiederkehrenden Bericht. Ein Formular rund um eine Tabelle. Ein Rechner mit einer hübscheren Oberfläche. Ein winziger Arbeitsablauf, der früher ein weiteres Monatsabo gerechtfertigt hat. Dort ist SaaS angreifbar: nicht im Zentrum, sondern an den Rändern.
SaaS hat viel „zu viel“ verkauft
SaaS hat gewonnen, weil Individualsoftware teuer war. Wenn ein Team ein Werkzeug für einen Arbeitsablauf brauchte, lautete die realistische Wahl nicht „SaaS kaufen oder genau das bauen, was wir brauchen“. Sie lautete „SaaS kaufen oder gar nichts tun“. Das Abo war billiger als ein internes Projekt. Das generische Produkt war einfacher als Spezifikation, Entwicklung, Hosting, Updates und Wartung.
Dieser Handel hat einen riesigen Markt für Software geschaffen, die oft größer war als der tatsächliche Bedarf der Nutzer. Sie abonnierten ein Produkt, weil Sie fünf Prozent davon brauchten. Sie passten Ihre Arbeit an sein Modell an. Sie nahmen die zusätzlichen Funktionen als Preis dafür hin, nicht selbst zu bauen. Sie nahmen das Konto hin, weil die Oberfläche im System des Anbieters lebte. Sie nahmen das Datenmodell hin, weil der Arbeitsablauf dort lebte.
KI-App-Builder greifen genau diesen Handel an. Sie müssen ausgereifte SaaS-Produkte nicht Funktion für Funktion schlagen. Nein, sie müssen nur die nützlichen fünf Prozent so billig machen, dass sich das Selberbauen lohnt.
Deshalb ist Funktionsgleichheit der falsche Test. Ein persönlicher Trello-Klon scheitert nicht daran, dass ihm die Enterprise-Administration fehlt. Er scheitert nur, wenn die Person, die ihn nutzt, Enterprise-Administration gebraucht hätte. Ein lokales Schreibwerkzeug scheitert nicht daran, dass es nicht Word ist. Es scheitert nur, wenn die fehlenden Teile genau die waren, auf die es ankam.
Die Miete ist nicht verschwunden
Aber es gibt einen Haken. Der Großteil der aktuellen Selbstbau-Welle holt Software nicht nach Hause. Er verschiebt sie von einem gemieteten System in einen anderen gemieteten Stack. Eine generierte App braucht immer noch einen Ort, an dem sie läuft. Sie braucht eine Datenbank, Speicher, Authentifizierung, Hosting, Modellaufrufe, Logging, Deployment und manchmal Zahlungen, E-Mail, Dateiverwaltung oder Integrationen. Das alte Abo mag verschwinden, aber darunter taucht ein neuer Haufen von Verbrauchszählern auf.
Der Nutzer zahlt nicht mehr für ein fertiges SaaS-Produkt, sondern für die Zutat, und die Miete ist von der Seat-Lizenz zum Stack gewandert. Sie ist von der Anwendung zur Infrastruktur gewandert, vom Produkttarif zu Credits, Hosting, Auth, Datenbanken und Inferenz.
Das ist kein kleiner Unterschied. Das neue Werkzeug passt vielleicht besser. Es ist vielleicht billiger, lässt sich vielleicht schneller ändern und ist vielleicht näher an der Arbeit. Es beseitigt vielleicht das seltsame Missverhältnis zwischen einem generischen SaaS-Produkt und einem konkreten Arbeitsablauf. Aber die Laufzeitumgebung gehört immer noch jemand anderem, die Datenbank liegt woanders und das Modell auch. Das Deployment liegt woanders, und natürlich brauchen Sie ein Konto. Und, am wichtigsten: Der Zähler läuft weiter. Deshalb ist der Großteil der heutigen „Post-SaaS“-Geschichte nicht wirklich Post-SaaS. Ich halte es für entbündeltes SaaS: Statt eines Anbieters, dem das ganze Produkt gehört, gehören mehreren Anbietern die einzelnen Schichten.
Der Markt hat die Bedrohung bemerkt
Investoren haben begonnen, dieses Problem einzupreisen. Im Februar 2026 beschrieb Forrester einen großen Ausverkauf bei Software-Aktien als Reaktion auf KI-Agenten und auf die Angst, dass Software-Arbeitsabläufe selbst neu bewertet würden. Die Panik bestand nicht darin, dass die Leute keine Software mehr brauchten. Sie bestand darin, dass die alte SaaS-Wachstumsgeschichte weniger sicher aussah, wenn Agenten über Werkzeuge hinweg arbeiten, kleine Anwendungen generieren und den Wert von Seat-Lizenzen senken können. Später legte sich diese Panik, und die Software-Aktien erholten sich. SaaS war also doch nicht tot: 2026 spürte SaaS schlicht den Druck vom Long Tail.
Die Antwort der etablierten Anbieter ist schon sichtbar. Alle SaaS-Produkte sind agentisch geworden, mit schlankeren Oberflächen und Arbeitsabläufen, die in eine KI-Schicht wandern. Die Preismodelle entfernen sich von einfachen Seat-Lizenzen hin zu Nutzung, Automatisierung oder Ergebnissen. SaaS-Anbieter versuchen, der Ort zu bleiben, an dem die Arbeit passiert, auch wenn der Nutzer sich nicht mehr durch die alten Bildschirme klickt.
Aber das erhält dieselbe Grundkonstellation: Nur die Anwendung ändert ihre Form, die Miete bleibt. Schließlich ist der KI-Tarif immer noch ein Tarif in einer SaaS-Lösung, und auch der Agent läuft immer noch irgendwo. Der Arbeitsablauf hängt weiter von einem Anbieter ab, und die Daten liegen weiter in dem System, das gebaut wurde, um sie abzurechnen.
Die lokale Version ist anders
Die interessantere Frage ist nicht, ob KI SaaS umbringt. Die Frage ist, welche Teile von SaaS nie SaaS hätten sein müssen. Eine Datei kann Daten halten. Ein Browser kann eine Oberfläche darstellen. Ein lokales Modell kann dabei helfen, die Datei zu ändern. Eine kleine Anwendung kann als Artefakt leben statt als Dienst. Der Nutzer kann sie öffnen, benutzen, ändern, kopieren, sichern und verschieben, ohne einen Anbieter zu fragen. Das ist die Version, die die aktuelle Marktdebatte meist ignoriert.
Die gängige Erzählung von den KI-Buildern setzt weiterhin eine gehostete Laufzeitumgebung voraus. Die Local-First-Version fragt, was passiert, wenn dem Artefakt mehr vom Stack gehört. Nicht nur der Inhalt, sondern auch die Oberfläche. Nicht nur die Oberfläche, sondern auch der Bearbeitungsmechanismus. Nicht nur der Bearbeitungsmechanismus, sondern auch die Fähigkeit, sich zu ändern, ohne den Umweg über ein Cloud-Produkt zu nehmen.
Das macht daraus keine Enterprise-Software. Es löst Compliance, Synchronisation, Identität, Mehrbenutzer-Berechtigungen, Backups oder Sicherheit nicht durch Magie. Es heißt auch nicht, dass jeder Arbeitsablauf zu einer lokalen Datei werden sollte. Aber es verändert die Wartungsfrage für kleine Software.
Das stärkste Argument für SaaS ist die Wartung
Die Geschichte vom Selberbauen hat eine offensichtliche Schwäche: Software ist nicht zu Ende, wenn sie zu funktionieren beginnt. Sie geht kaputt. Anforderungen ändern sich. Randfälle tauchen auf. Datenformate driften. Nutzer tun Unerwartetes. Sicherheitsprobleme verstecken sich in den Teilen, die sich niemand angesehen hat. Ein Werkzeug, das als Demo beeindruckend war, kann als Infrastruktur gefährlich werden.
Das Risiko ist schon sichtbar. Axios berichtete, dass vibe-codierte Apps, gebaut mit Werkzeugen wie Lovable, Replit, Base44 und Netlify, Hunderttausende öffentliche Assets offengelegt hatten, darunter Tausende mit sensiblen Unternehmensinformationen. Das ist kein Argument gegen KI-App-Builder. Es ist ein Argument dagegen, so zu tun, als wären Erstellung und Betrieb dasselbe.
SaaS hingegen bündelt die Wartung ins Abo. Das ist ein Teil dessen, wofür der Nutzer zahlt. Der Anbieter hostet, patcht, überwacht, sichert ab, dokumentiert, aktualisiert, leistet Support und nimmt einen Teil der Schuld auf sich, wenn etwas schiefgeht.
Ein Local-First-Stack muss darauf eine Antwort haben. Er kann nicht einfach sagen „dem Nutzer gehört die Datei“ und die Kosten des Besitzes ignorieren, denn Besitz ohne Wartung ist bloß Verantwortung. Für das Lohnverrechnungssystem eines Unternehmens reicht das nicht, für ein privates Board vielleicht schon.
Das Post-SaaS-Szenario
Viel SaaS ist schwerer als die Aufgabe, die es erledigt. Am leichtesten sieht man das bei Software für Einzelpersonen und kleine Teams. Ein Aufgaben-Board, eine Schreibfläche, ein Planungswerkzeug, ein Tracker, ein Dashboard, ein schlankes CRM, ein Projektnotizbuch, eine Recherchedatenbank, ein Angebotsrechner, eine Statusseite. Das sind oft keine „Anwendungen“ im großen Sinn. Es sind strukturierte Dokumente mit Verhalten. Das ergab Sinn, solange die Alternative gar kein Werkzeug war. Es ergibt weniger Sinn, wenn die Alternative eine Datei ist, die sich wie genau der Teil des Produkts verhält, den der Nutzer tatsächlich gebraucht hat.
Die erste KI-Softwarewelle hat bewiesen, dass Menschen ihre eigenen Werkzeuge bauen, wenn die Schwelle niedrig genug ist. Die nächste Frage ist, ob sie sie auch besitzen wollen. Nicht alle. Nicht die großen Systeme. Nicht die regulierten Kerne. Nicht die gemeinsame operative Maschinerie großer Unternehmen. Aber die kleinen Werkzeuge, die persönlichen Arbeitsabläufe, die internen Hilfsprogramme, die Halbprodukte, die nur deshalb SaaS waren, weil SaaS der einfachste Weg war, eine Oberfläche auszuliefern und ein paar Daten zu speichern.
Der lokale Post-SaaS-Stack ist als Massenverhalten noch nicht da. Die gehosteten Builder gewinnen, weil sie einfacher sind. Die Cloud bleibt der Standard, weil Konten, Synchronisation, Teilen, Speicher und Deployment bequem sind. Lokale Modelle werden besser, aber die Werkzeuge rund um sie sind noch umständlich, auch wenn sie sich schnell verbessern.
Im tatsächlichen Post-SaaS-Szenario geht es also um den nützlichen Teil eines SaaS-Produkts, der dem Produkt jetzt entkommen und auf einem lokalen Rechner in einem Verzeichnis landen kann. Ein Board kann zu einer Datei werden. Ein Schreibwerkzeug kann zu einer Datei werden. Ein Arbeitsablauf kann zu einer Datei werden. Die Bearbeitungsschleife kann bei ihr bleiben, und das Modell kann auf demselben Rechner laufen.
Die Leute haben begonnen, ihre eigene Software zu bauen. Was die meisten noch nicht getan haben: die Laufzeitumgebung nach Hause holen. Das ist nicht das Ende von SaaS, aber das Ende der Miete für die kleinen Dinge, die nie Dienste hätten sein müssen.
Aus dem Englischen übersetzt: zum Originalbeitrag