35% der Unternehmen haben 2026 bereits eine SaaS-Kategorie durch einen Eigenbau ersetzt. 78% planen es für die kommenden Monate. Das sind nicht zwei interessante Zahlen. Das ist eine Disruption, die gerade leise stattfindet — parallel zu allem anderen, was an KI-Schlagzeilen durch die Branche zieht.

Der eigentliche Treiber dieser Verschiebung ist nicht Strategie. Es ist KI-Coding. Cursor, Claude Code, Lovable und ihre Generation haben die Kosten des Selbstbauens kollabieren lassen — und damit eine Logik gekippt, die zwanzig Jahre stabil war. Wer das versteht, sieht: was sich abzeichnet, ist keine neue „Build vs. Buy"-Debatte. Es ist eine neue Architektur in drei Schichten, mit klaren Gewinnern und klaren Verlierern.

Dieser Bericht skizziert, was dabei stirbt, was überlebt, wer gewinnt — und welche Fehler Entscheider gerade machen.

Die Zahlen stammen aus dem Retool 2026 Build vs. Buy Report: 35% der Unternehmen haben mindestens ein SaaS-Werkzeug bereits durch einen internen Eigenbau ersetzt. 78% planen, in den kommenden Monaten weitere zu bauen statt zu lizenzieren. Das ist keine kleine Stichprobe — das ist die größte jährliche Erhebung zu diesem Thema, mit einem klaren Trendbruch gegenüber 2024 und 2023.

Gartner ergänzt: Bis Ende 2026 enthalten 40% der Unternehmensanwendungen task-spezifische KI-Agenten. Heute sind es unter 5%. Das ist innerhalb von zwölf Monaten ein Faktor 8.

Beide Datenpunkte beschreiben dieselbe Bewegung aus zwei Winkeln. Unternehmen bauen mehr selbst. Und sie statten ihre Anwendungen — egal ob gekauft oder gebaut — mit KI-Agenten aus, die zwischen den Schichten vermitteln.

Warum diese Verschiebung in Vorstandspräsentationen so selten auftaucht: Sie passiert nicht in der zentralen IT. Sie passiert in den Operations-Teams, bei den RevOps, in einzelnen Geschäftsbereichen. Dort, wo die Distanz zwischen einer konkreten Workflow-Lücke und der Person, die sie schließen kann, gerade auf null zusammengeschrumpft ist.

Die Build-vs-Buy-Frage hatte über zwei Jahrzehnte eine einfache Antwort: kaufen. Eigenbau war zehn- bis zwanzigmal so teuer wie eine Lizenz. Die Mathematik war eindeutig.

Diese Mathematik ist jetzt zerbrochen.

Was vor zwei Jahren ein 6-Monats-Projekt war, baut heute eine kleine Truppe in zwei Wochen. Cursor, Claude Code, Lovable, GitHub Copilot mit Managed Agents — alle haben dieselbe Eigenschaft: sie kollabieren die Kosten des Code-Schreibens. Wenn ein einzelner Entwickler mit einem agentischen Werkzeug die Output-Geschwindigkeit eines Drei-Personen-Teams aus 2023 erreicht, kippt jede Kalkulation, die auf der alten Geschwindigkeit basiert.

Konkret: Wenn Eigenbau gleich teuer ist wie eine Lizenz — und exakt auf die eigenen Prozesse passt — gibt es keinen ökonomischen Grund mehr zu kaufen. Im Gegenteil: jeder gekaufte Standardbaustein, der nicht passt, verursacht jetzt Kosten, die früher unsichtbar waren. Anpassungen am Prozess statt am Werkzeug. Workarounds, die Datenqualität degradieren. Lizenzgebühren, die mit der Nutzung skalieren, aber nicht mit dem Wert.

Wichtig dabei: Es geht nicht um „KI macht Entwickler 20% schneller". Tatsächlich zeigt die METR-Studie von 2025 das Gegenteil — Entwickler glauben mit KI-Tools 20% schneller zu sein, sind aber 19% langsamer in den gemessenen Aufgaben. Der eigentliche Effekt ist anders gelagert: Es geht um neue Arten von Arbeit, die jetzt für andere Personengruppen zugänglich werden. Ein Operations-Manager, der nie eine Zeile Python geschrieben hat, kann mit Claude Code ein internes Werkzeug bauen, das eine maßgeschneiderte Workflow-Lücke schließt. Das war 2023 unmöglich.

Diese Verschiebung der Zugänglichkeit ist der Treiber — nicht die Geschwindigkeit der bestehenden Entwickler.

Ryan Salva, ehemals GitHub Copilot, hat ein Modell mit fünf Stufen vorgeschlagen, das die Entwicklung von KI-Coding-Werkzeugen einordnet:

Wir stehen auf Stufe 3. Die meisten produktiven Teams arbeiten heute mit Werkzeugen, die den Code-Kontext über mehrere Dateien hinweg verstehen — Cursor mit großen Kontextfenstern, Claude Code mit Projekt-Indexierung, Lovable mit ganzen Anwendungs-Templates.

Stufe 4 ist die nächsten 18 bis 36 Monate. Stufe 5 ist die 5-bis-10-Jahre-Vision. Das heißt: die Disruption, die der Retool-Report misst, ist nicht das Ende. Sie ist der Anfang. Stufe 4 — Agenten, die auf Pull-Requests, Build-Failures, Pager-Duty-Alerts reagieren — wird die Build-vs-Buy-Logik nochmal verschärfen. Wenn ein Agent 24/7 an einem internen Werkzeug weiterarbeitet, wird der Wartungsaufwand, der Eigenbau bisher teuer machte, weiter sinken.

Wer in den nächsten Jahren die größten Verluste sehen wird, hat ein gemeinsames Merkmal: er sitzt zwischen einem Menschen und einer Datenbank. CRUD plus etwas Geschäftslogik, plus eine Benutzeroberfläche.

Sechs Kategorien mit hohem bis sehr hohem Disruptionsrisiko:

VCs reagieren. Wer Pitch-Decks dieser Saison vergleicht: dünne KI-Wrapper und reine Integrations-Plattformen werden konsequent ausgesiebt. Der Burggraben ist weg.

Skalierung, Komplexität und Regulierung schützen vier Kategorien:

Vertikale SaaS in regulierten Nischen. Healthcare, Legal, Finance, Compliance. Hohe ACVs, niedrige Churn-Raten, regulatorische Last als natürlicher Burggraben. Niemand baut sich seine eigene Steuerprüfungs-Software — der regulatorische Aufwand pro Funktion ist zu hoch.

Systeme mit proprietären Daten. Jahre an akkumuliertem Datenbestand sind nicht reproduzierbar. Hier ist die Daten der eigentliche Wert — nicht die Benutzeroberfläche. Eigenbau bringt nichts, wenn die Daten woanders liegen.

Plattformen mit echten Netzwerkeffekten. Marktplätze, Communities, mehrseitige Plattformen. Der Wert wächst mit jedem zusätzlichen Teilnehmer. Das lässt sich nicht im Haus replizieren.

Infrastruktur-SaaS. Cloud, Datenbanken, Observability, Security. Die Schaufeln und Spitzhacken der KI-Bau-Ära. Wer ein internes Werkzeug baut, braucht trotzdem eine Datenbank, einen Cloud-Anbieter, eine Logging-Schicht. Diese Anbieter profitieren von jedem Eigenbau.

Was alle vier eint: ihr Burggraben liegt nicht in der Software-Schicht selbst. Er liegt in dem, was außen drumherum liegt — Regulatorik, Datenakkumulation, Netzwerk, Skalen-Effekte.

Aus dieser Verteilung folgt eine klare Architektur — drei Schichten, jede mit eigener Logik:

Schicht 1: Vertikale Premium-SaaS für den Compliance-Kern. Healthcare, Legal, Finance, Audit. Hier zahlt man gerne. Die Regulatorik ist der Burggraben des Anbieters. Eigenbau wäre wirtschaftlicher Selbstmord.

Schicht 2: KI-Agenten als Bindegewebe. Orchestrierung, Workflow-Execution, MCP. Sie verbinden, sie differenzieren nicht. Diese Schicht ist der Mechanismus, über den die anderen beiden zusammenarbeiten — sie übersetzt zwischen Datenbanken, Anwendungen, externen Diensten und den Eigenbauten der dritten Schicht.

Schicht 3: Custom AI-Built Tools für alles, was wirklich differenziert. Interne Anwendungen, BI-Werkzeuge, Workflow-Bauten, Operations-Tools. Gebaut von kleinen Teams oder Einzelpersonen, mit KI-Werkzeugen, in Wochen statt Quartalen. Hier liegt der Wettbewerbsvorteil.

Die Faustregel: Kaufe, was reguliert ist. Baue, was differenziert. Lass Agenten es verbinden.

Wer noch in zwei Schichten denkt — alles kaufen oder alles bauen — hat das Modell nicht verstanden. Die Disruption liegt nicht in der Build-Entscheidung. Sie liegt in der Erkenntnis, dass moderne Unternehmen eine Orchestrierungs-Schicht brauchen, die früher schlicht nicht existierte.

Sieben Branchen profitieren am stärksten — alle haben spezifische Workflows, proprietäre Daten, und Spielraum für Differenzierung:

Der Sweet Spot — also der Punkt, ab dem Eigenbau systematisch billiger wird als SaaS — liegt bei 500+ Mitarbeitern oder $500K+ jährlichen SaaS-Ausgaben. Über fünf Jahre lassen sich dort etwa 40% Einsparungen realisieren, mit besserer Workflow-Passung als Bonus.

Wer treibt den Shift? Nicht die IT. Nicht die Anbieter. Es sind sechs Personengruppen, die alle eine Eigenschaft teilen: sie sind dem Workflow näher als alle anderen.

Das ist eine bemerkenswerte Verteilung. Die Personen mit dem größten Hebel sitzen nicht zentral. Sie sitzen im Geschäftsprozess.

Der größte Fehler: Warten. Wer 2026 abwartet, ob sich der Trend bestätigt, gibt zwölf bis achtzehn Monate Wettbewerbsvorteil ab. Die Konkurrenz baut bereits.

Der zweitgrößte Fehler: alles selbst bauen. Compliance-kritische Bereiche bleiben sinnvoll lizenziert — die regulatorische Last ist real, der Burggraben des Anbieters auch. Wer hier baut, baut sich seinen eigenen Audit-Aufwand.

Für regulierte Branchen — Banken, Versicherungen, Medizintechnik, Energieversorger — gilt eine zusätzliche Dimension: KI-generierter Code in Compliance-kritischen Kontexten erzeugt eine neue Risikofläche. Der Code funktioniert oft. Aber: Welche Datenfelder referenziert er? Sind die Endpunkte autorisiert? Sind die regulatorischen Anforderungen — EU AI Act, DORA, MaRisk — eingehalten? Diese Fragen lassen sich nicht im selben Werkzeug beantworten, das den Code generiert hat.

Hier entsteht eine Schicht, die in der bisherigen Architektur nicht vorgesehen war: Code-Governance. Sie sitzt zwischen den agentischen Werkzeugen, die Code produzieren, und den Systemen, die ihn ausführen. Sie prüft semantisch — nicht ob der Code syntaktisch funktioniert, sondern ob er zum echten Projekt, zu echten Daten und zur geltenden Regulatorik passt.