Foto: Google Gemini · AI-generated
Zwei Jahrzehnte lang lautete die Standardantwort auf die Frage “Eigenentwicklung oder Standardsoftware?” fast immer: Standardsoftware. Eine etablierte Plattform zu lizenzieren bedeutete erprobte Funktionalität, Herstellersupport und einen Bruchteil der Kosten eines eigenen Entwicklungsteams. Eigenentwicklung war die Ausnahme, reserviert für das, was wirklich zum Kerngeschäft gehörte. Dieser Standard verschiebt sich. Ein Build-vs-Buy-Report von Retool aus dem Jahr 2026 zeigt: 35 % der befragten Teams haben bereits die Funktionalität mindestens eines SaaS-Tools durch eine Eigenentwicklung ersetzt, und 78 % planen, dieses Jahr weitere individuelle Tools zu bauen. KI-gestützte Design- und Coding-Tools sind der Grund dafür — und die Verschiebung ist rational, nicht leichtsinnig, wenn man versteht, was sich tatsächlich verändert hat.
Die alte Logik ging davon aus, Eigenentwicklung sei teuer. Das stimmt noch immer — nur weniger als früher
Standardsoftware für Unternehmen wird für den Durchschnittskunden gebaut, nicht für Ihre Organisation. Jede Konfigurationsoption, jeder Workflow, jedes Feld in jedem Formular ist ein Kompromiss zwischen dem, was Sie brauchen, und dem, was tausende andere Kunden auch brauchen. Die Software wirklich an die eigenen Abläufe anzupassen, bedeutet teure Beratertage — und selbst dann ist das Ergebnis selten eine perfekte Passform. Das zugrunde liegende Datenmodell, die im Workflow-Engine eingebauten Annahmen, die Stellen, an denen die Meinung des Herstellers darüber, “wie dieser Prozess ablaufen sollte”, nicht zu Ihrer eigenen passt — all das verschwindet nicht durch Konfiguration. Es wird umgangen, und der Workaround wird zu einer dauerhaften, leise teuren Belastung genau des Prozesses, den er eigentlich reparieren sollte.
Das war schon immer so. Was sich verändert hat, ist die andere Seite des Vergleichs. KI-gestützte Coding-Tools haben die Kosten und die Zeit für den Bau einer maßgeschneiderten Anwendung spürbar gesenkt — nicht, indem sie fachliches Urteilsvermögen ersetzen, sondern indem sie die mechanischen Teile davon verkürzen: Boilerplate, Grundgerüst, erste Implementierungen gut verstandener Muster. Ein individuelles internes Tool, das vor zwei Jahren noch Monate an Budgetrechtfertigung gebraucht hätte, lässt sich heute in Wochen skizzieren, bauen und ausliefern. Das ist die eigentliche Verschiebung: Eigenentwicklung war schon immer präziser, Standardsoftware war schon immer schneller startklar — und genau die Lücke bei “schneller startklar” ist deutlich kleiner geworden.
Zwei einfache Beispiele
Nehmen wir einen Freigabeprozess für neue Lieferanten: Drei Abteilungen müssen in einer bestimmten Reihenfolge zustimmen, mit unterschiedlichen Ausnahmepfaden je nach Risikokategorie und Vertragsvolumen des Lieferanten. Eine generische Beschaffungsplattform kann das meist annähern — mit ausreichend Konfiguration, einem Berater und ein paar Monaten. Ein schlankes, eigens gebautes Freigabe-Tool, das genau diese drei Schritte und genau diese Ausnahmepfade abbildet, lässt sich direkt an der tatsächlichen Arbeitsweise der Organisation ausrichten, in einem Bruchteil der Zeit, ohne Konfigurations-Altlasten, die später gepflegt werden müssen.
Oder nehmen wir zwei Systeme, die jeweils ihre Aufgabe gut erfüllen, aber nie dafür gebaut wurden, Daten miteinander zu teilen — etwa ein Warenwirtschaftssystem und ein Vertriebskanal-Tool mit unterschiedlichen SKU-Schemata und ohne gemeinsame Kennung. Eine dritte Plattform zu kaufen, die darüber gestülpt wird, löst das selten sauber — sie fügt lediglich eine dritte Meinung darüber hinzu, wie das Mapping aussehen sollte. Eine kleine, eigens gebaute Reconciliation-Schicht, die beide Systeme und ihre tatsächlichen Daten wirklich versteht — einmal gebaut, vollständig verstanden — dient dem Unternehmen meist besser als ein generisches BI-Tool, das ein Mapping erraten soll, für das es nie konzipiert wurde.
Wie das bei uns konkret aussieht
Das sind keine Gedankenspiele. Ein Einkaufsportal, das wir gebaut haben, hat das bestehende Sage-100-ERP eines Herstellers um einen eigens entwickelten Beschaffungsworkflow erweitert — statt ein generisches Procurement-Modul zu zwingen, einen Prozess nachzubilden, für den es nicht gemacht war — als Full Application Lifecycle Management-Engagement für einen Mittelstands-Kunden in der industriellen Fertigung. Eine Besucher-Compliance-App hat generische Besuchermanagement-Software durch einen Compliance-Workflow ersetzt, der exakt auf die regulatorischen Pflichten eines Herstellers über mehrere Standorte hinweg zugeschnitten ist. Eine Supply-Chain-Intelligence-Plattform hat einem Bekleidungshersteller die Reconciliation-Schicht zwischen zwei Systemen geliefert, die eine dritte Standardplattform nie hätte leisten können, im Modell Zeit & Aufwand. Und ReportSync — ein kleines, eigens gebautes Sync-Tool für einen Kunden aus der Chemieindustrie — läuft seit Jahren unter Managed Support & Wartung und erledigt genau eine Aufgabe gut, statt eine Ecke einer Plattform zu sein, die viele Aufgaben nur ausreichend erledigt.
Der Teil, den KI nicht abkürzt
Das heißt nicht, dass “alles selbst bauen” jetzt der sichere Standardweg ist. KI-gestützte Tools senken die Kosten fürs Schreiben von Code — sie senken nicht die Kosten dafür, Code zu schreiben, der den Kontakt mit den echten Ausnahmefällen einer Organisation übersteht, auch nach der zweiten Anforderungsänderung noch funktioniert und nicht leise zu der Sache wird, die niemand mehr versteht, sobald die Autorin oder der Autor das Unternehmen verlässt. Das ist immer noch Ingenieursarbeit — die Entscheidung, was gebaut wird, nicht nur wie schnell getippt wird. Es ist auch genau der Teil, den Standardsoftware standardmäßig richtig macht, und der Teil, den eine überstürzte interne Eigenentwicklung am häufigsten falsch macht.
Die Organisationen, die aus dieser Verschiebung echten Wert ziehen, behandeln “Eigenentwicklung” als ernsthafte Custom-Software-Entscheidung, nicht als Wochenendprojekt — und kombinieren KI-gestützte Tools mit Menschen, die wissen, wie man sie einsetzt, genau auf den Prozess, für den Standardsoftware nie gepasst hätte. Sagen Sie uns, wogegen Ihre Standardsoftware gerade kämpft — wir sagen Ihnen ehrlich, ob sich eine Eigenentwicklung dafür lohnt.