35 % der Teams haben ein SaaS-Tool durch eigene Software ersetzt. Sollten Sie auch?

Anfang Februar hat ein Produkt-Update von Anthropic an einem einzigen Tag Milliarden vom Börsenwert der Enterprise-Software-Branche radiert. Händler nannten es die SaaSpocalypse: Der Markt preiste kurzzeitig eine Welt ein, in der Unternehmen Software nicht mehr kaufen, sondern selbst bauen. Zwei Wochen später veröffentlichte Retool seinen Build-vs.-Buy-Report 2026, und die Umfragedaten stützten die Stimmung. Von 817 befragten Buildern hatten 35 % bereits mindestens ein SaaS-Tool durch etwas Eigenes ersetzt, und 78 % planen, dieses Jahr mehr zu bauen.

Wir bauen beruflich individuelle Software, also könnten Sie Jubel von uns erwarten. Meist zucken wir eher zusammen. Was der Report tatsächlich beschreibt, ist eine Welle schnellen und weitgehend unkontrollierten Bauens, die einige echte Erfolge hervorbringen wird und daneben viele verwaiste Tools, die niemand wartet. In welcher Gruppe Sie landen, entscheidet sich, bevor jemand den ersten Prompt schreibt.

Was der Report wirklich sagt

Zuerst der Vorbehalt, den die Pressemitteilungen weglassen: Retool hat Ende 2025 die eigenen Kunden und Builder befragt, 817 an der Zahl. Das sind Leute, die bereits eine Plattform zum Tool-Bauen gekauft haben. Sie zu fragen, ob sie gern Tools bauen, ist ein bisschen so, als würde man im Fitnessstudio eine Umfrage zum Thema Sport machen. Die Richtung ist aufschlussreich; die genauen Prozentwerte sollte man mit Vorsicht genießen.

Mit diesem Filter sagen die Ergebnisse trotzdem einiges. Jede SaaS-Kategorie steht unter Ersetzungsdruck: Workflow-Automatisierungen (35 %) und interne Admin-Tools (33 %) führen, BI-Tools liegen bei 29 %, CRMs und Formular-Builder bei 25 %, Projektmanagement bei 23 %, Kundensupport bei 21 %. Die Fallstudien sind konkret. ClickUp hat sechs interne KI-Tools gebaut und spart damit 200.000 US-Dollar pro Jahr an Automatisierungssoftware. Harmonic hatte genug von einem Tool für 20.000 US-Dollar im Jahr, dessen Support langsamer war als der Nachbau des Produkts, also haben sie es nachgebaut und betreiben heute 33 interne Apps.

Und dann die Zahl, die Sie bremsen sollte: 60 % der Builder haben im vergangenen Jahr etwas außerhalb der IT-Aufsicht ausgeliefert. Nach dem Warum gefragt, sagten sie: Sie könnten schneller bauen, als die IT beschaffen kann (31 %), das vorhandene SaaS könne nicht, was sie brauchen (25 %), oder der IT-Prozess sei schlicht zu langsam (18 %). Das sind keine Praktikanten mit einem Wochenendprojekt; 64 % der Befragten waren Senior Manager oder höher.

Warum die Rechnung gekippt ist

Zwanzig Jahre lang war die Build-vs.-Buy-Rechnung stabil. Bauen hieß: Entwickler einstellen, zwei Quartale warten und die Wartung für immer am Hals haben. Kaufen hieß: Kreditkarte. Für alles, was nicht das Kernprodukt war, gewann Kaufen per Default, und meistens war das die richtige Entscheidung.

KI hat diese Rechnung nicht angepasst. Sie hat eine Seite davon umgeworfen. Ein funktionierendes internes Tool (ein Dashboard, ein Freigabe-Workflow, ein CRM-artiges Ding, das zu Ihrem leicht eigenwilligen Vertriebsprozess passt) ist heute eine Sache von Tagen, manchmal Stunden. Wenn der Bau so wenig kostet, ist ein Abo über 15.000 US-Dollar für Software, die Ihr Team nur halb nutzt, kein sicherer Default mehr, sondern ein Budgetposten, den jemand hinterfragen sollte.

Aber beachten Sie, was das Abo für sich hatte: ein Preisschild. Sie wussten, was es kostet. Ein eigener Bau versteckt seine Kosten an Stellen, an die das Finanzteam nicht schaut, und genau dort geht es in vielen Unternehmen gerade schief.

Der Teil, den niemand einkalkuliert

Derselbe Report listet die größten organisatorischen Blocker für Automatisierung auf: unklarer ROI (33 %), Budget (30 %), Wartungsaufwand (26 %). Und 35 % der Organisationen haben überhaupt keine KI-Produktivitätsmetriken etabliert. Zusammengenommen ergibt das ein unbequemes Bild: Unternehmen tauschen messbare Abos gegen ungemessene interne Tools, in großem Stil, oft ohne dass die IT von dem Tool weiß.

Wir haben schon früher über das Monat-3-Problem in der KI-gestützten Entwicklung geschrieben: Der Prototyp kommt schnell und fühlt sich nach Magie an, und die Rechnung kommt um Monat drei, wenn das Ding plötzlich Auth, Berechtigungen, Audit-Logs und jemanden in Rufbereitschaft braucht. Interne Tools folgen demselben Bogen. Der Ops-Lead, der das Dashboard gebaut hat, wechselt das Team. Die API, auf der es aufsetzt, ändert ihre Form. Niemand sonst kann den generierten Code lesen. Jetzt läuft ein Stück Ihrer Revenue Operations auf einem Tool mit einem Bus-Faktor von eins.

Mit einer vibe-gecodeten Lösung können Sie unmöglich live gehen. Für Demos mag das funktionieren, aber wir bauen Enterprise-Technologie, die über 30 Länder hinweg skalieren muss.

Das Zitat stammt von Pierre Yves Calloc'h von Pernod Ricard, aus demselben Retool-Report, der die Bauwelle feiert. Beides stimmt gleichzeitig. Das Bauen ist real, die Erfolge sind real, und die Messlatte für den Produktivbetrieb hat sich keinen Zentimeter bewegt.

Es gibt einen Präzedenzfall dafür, wie das ausgeht, wenn man die Messung überspringt. Gartner prognostiziert, dass die Hälfte der Unternehmen, die für KI Kundenservice-Personal abgebaut haben, diese Stellen bis 2027 wieder besetzen wird. Software kann dieselbe Schleife drehen: Abo kündigen, die Demo genießen, in achtzehn Monaten stillschweigend wieder abonnieren, nachdem das interne Tool verrottet ist. Retools eigener Report bringt es gut auf den Punkt: Ersatz ohne Messung ist nur Churn.

Ein kurzes Entscheidungsraster

Ersetzen lohnt sich, wenn das Tool generisch ist und Ihr Prozess nicht. Die Kategorien an der Spitze der Druckliste (Workflow-Automatisierung, interne Admin-Tools, Dashboards) sind meist dünne Softwareschichten über Ihren eigenen Daten. Wenn Sie hundert Lizenzen bezahlen und zwölf nutzen, oder zweihundert Features bezahlen und neun nutzen, schlägt Passung die Featureliste, und der eigene Bau gewinnt. Die Harmonic-Geschichte ist die Vorlage: In dem Moment, in dem das Abo mehr an Workarounds kostet, als der Bau insgesamt kosten würde, bauen Sie.

Weiter kaufen sollten Sie, wenn Ihr Prozess nichts Besonderes ist (Lohnabrechnung, Buchhaltung, E-Mail), wenn Compliance das eigentliche Produkt ist oder wenn der Wert im Ökosystem des Anbieters liegt statt in seinen Oberflächen. Niemand sollte das System, das ihn HIPAA-konform hält, selbst nachbauen, um 400 US-Dollar im Monat zu sparen.

Und was immer Sie bauen: Machen Sie es absichtlich langweilig. Ein richtiges Repository, Zugriffskontrolle, Fehler-Monitoring, ein Owner, dessen Namen alle kennen, und eine Kennzahl, die Sie regelmäßig prüfen: gesparte Stunden, geschlossene Tickets oder eingesparte Dollar. Das ist der ganze Unterschied zwischen einem Asset und einer Altlast. Die Retool-Daten zeigen, dass Builder das instinktiv schon verstanden haben: 72 % derer, die echte Software ausliefern, nutzen KI, um einzelne Code-Stücke zu schreiben, die sie testen und integrieren, während sich nur 31 % komplette Apps zusammenprompten. Produktionssoftware lebt in der ersten Gruppe.

Die Lücke zwischen einem geprompteten Prototyp und einem Tool, auf das sich Ihr Unternehmen verlassen kann, ist genau die Stelle, an der Teams wie unseres gerufen werden, meist um Monat drei. Der Prototyp ist dabei keine verlorene Arbeit, um das klarzustellen. Ein vibe-gecodetes Tool, das Ihr Ops-Lead gebaut hat und das das ganze Team bereits nutzt, ist das beste Anforderungsdokument, das uns je übergeben wurde. Es ist nur nicht das fertige Produkt, und es wie eines zu behandeln, ist der Anfang der Wieder-Abonnieren-Schleife.

Also: Sollten Sie? Wenn ein Tool von der Hochdruckliste teuer ist, nur halb genutzt wird und im Kern um Ihre eigenen Daten gebaut ist: wahrscheinlich ja, und die Ökonomie wird sich nur weiter in diese Richtung neigen. Beantworten Sie nur eine Frage, bevor Sie irgendetwas kündigen: Wem gehört das in Monat drei? Gibt es einen Namen, bauen Sie. Gibt es ein Schulterzucken, zahlen Sie weiter.