Der Rebuild-Markt: Wenn der Prototyp auf echte Nutzer trifft
KI-Werkzeuge haben tausende Prototypen hervorgebracht, die den Sprung in den Produktivbetrieb nicht schaffen. Woran das liegt und wann sich ein Neubau einer bestehenden App rechnet.
- Vibe Coding bringt Prototypen schnell zum Laufen, aber Integration, Governance und Sicherheit bleiben genauso aufwendig wie vorher - teilweise mehr, denn mit Vibe Coding erzeugte Apps haben oft mehr Code als herkömmlich programmierte
- Nutzungsauswertungen zeigen bei KI-Coding-Plattformen Abwanderungsraten von 60% bis 80% binnen drei Monaten
- Ein Rebuild lohnt sich, wenn die fachliche Logik sich bewährt hat und nur die Architektur nicht mitkommt
Ein Prototyp, der nach zwei Tagen läuft, ist heute keine Besonderheit mehr. Andrej Karpathy hat dafür den Begriff Vibe Coding geprägt und ihn mit dem Rat verbunden, zu vergessen, dass der Code überhaupt existiert. Für einen Wegwerf-Prototypen ist das ein guter Rat. Für eine Anwendung, die Kundendaten verarbeitet und deren Funktion kritisch für das eigene Geschäft ist, ist es eine gefährliche Wette.
Einen Hinweis, ob Unternehmen gewillt sind, diese Wette einzugehen, zeigt eine Auswertung der Nutzungsverläufe mehrerer KI-Coding-Plattformen. Sie alle zeigen ein wiederkehrendes Muster: ein steiler Anstieg, dann ein Einbruch von 60% bis 80% binnen drei Monaten. Base44 legte im Mai 2025 um 950% zu und fiel bis Oktober zurück, Lovable drehte von +207% auf −37%, Cursor von +62% auf −19%. Die Erklärung dahinter ist unspektakulär: Der durchschnittliche Nutzer, typischerweise eben kein Entwickler, probierte es zwölf Wochen lang, stieß dann auf eine Wand und hörte abrupt auf.
Die Grenze der Werkzeuge
KI-Assistenten erzeugen zuverlässig Code, der eine Funktion erfüllt. Schwächer werden sie bei allem, was sich erst im Betrieb zeigt: komplexe Zusammenspiele verschiedener Bibliotheken und Schnittstellen, gleichzeitige Zugriffe auf denselben Datensatz, eine saubere Trennung, wer welche Daten sehen darf und das Verhalten bei unvorhergesehenen Fehlern.
Ein verbreiteter Einwand lautet, Unternehmenssysteme seien ohnehin oft nur mit Klebeband zusammengehalten. Aber dies blendet eine wesentliche Tatsache aus: Eine erprobte Low-Code-Plattform wie Zapier für Aufgaben außerhalb des Kerngeschäfts einzusetzen, ist eine vernünftige Entscheidung. Alter, unschöner Code, der zwanzig Jahre überlebt hat, ändert sich schwer, hat aber Jahrzehnte an Fehlerkorrekturen, Fachlogik, Audits und Sicherheitshärtung angesammelt. Das Weiterführen solcher Altlasten ist wirtschaftlich oft sinnvoll, auch wenn die Arbeit daran wenig effizient ist. Er läuft stabil. Ein Wegwerf-Prototyp ist es nicht, er muss die jahrelange Flickschusterei zur Stabilität erst nachvollziehen - mit Tests und Korrekturen - oder er stellt ein beträchtliches betriebliches Risiko dar. Vibe Coding Projekte scheitern an Stabilität und Betrieb, nicht am Funktionsumfang.
Der Rebuild als eigener Markt
Dieselbe Auswertung beziffert den daraus entstehenden Nachholbedarf auf 400 Mio. bis 4 Mrd. US-Dollar und beschreibt einen typischen Verlauf: Ein Gründerteam bringt ein MVP an den Start, gewinnt erste Kunden oder eine Vorfinanzierung, und als echte Nutzer auftauchen, beginnen die Probleme. Anschließend fließen 200.000 bis 300.000 Dollar an erfahrene Entwickler, um das Fundament der Software neu aufzubauen.
Diese Zahlen stammen aus der Beobachtung eines Marktteilnehmers, nicht aus einer Erhebung, und sind entsprechend vorsichtig zu lesen. Das Muster dahinter deckt sich mit dem, was wir in Projekten sehen: Nicht das Schreiben der Funktionen treibt die Kosten, sondern alles, was danach kommt.
Sie gilt aber vor allem für die Neuerstellung von Software. Bei der Modernisierung von Bestehendem sieht die Rechnung anders aus. Ein über Jahre gewachsenes Prozesssystem ließ sich in gut fünfzehn Stunden mit Claude Code und einer Reihe von Agenten neu aufbauen: aus einem Flickwerk aus manuellen Schritten, Vorlagen und Kopiervorgängen wurde ein durchgängiger Ablauf. Den Unterschied zum gescheiterten Prototypen macht die Ausgangslage. Nach Jahren im Betrieb war genau bekannt, was das System können muss. Neu gebaut wurde hier ein vertrauter Prozess, kein Entwurf.
Spezifikation statt Zuruf
Aus dem beschriebenen Wegwerf-Prototypen-Problem lässt sich folgendes lernen: Sobald Vibe Coding an seine Grenzen stößt, gehen Teams dazu über, ihre Absicht strukturiert zu formulieren. Die Entwicklungsumgebung Kiro beispielsweise zerlegt diese Absicht in requirements.md, design.md und tasks.md, angelehnt an die Easy Approach to Requirements Syntax (EARS), eine Schreibweise für maschinell prüfbare Anforderungen. Ändert sich die Spezifikation, entsteht die Aufgabenliste neu, und die Spezifikation bringt gleich Tests mit, die den Agenten in der Spur halten.
Dahinter steht eine alte Einsicht: Eine ungenaue Beschreibung der Anforderungen erzeugt Software, die irgendetwas leistet, gleich ob ein Mensch oder ein Agent sie schreibt.
Für uns bestätigt das die eigene Arbeitsweise. Unsere Plattform besteht aus vorgefertigten Bausteinen für Mandantenfähigkeit, Rechteverwaltung, Fakturierung und Änderungshistorie. Diese Teile sind spezifiziert, getestet und im Kundenbetrieb gehärtet. KI beschleunigt bei uns den individuellen Teil einer Anwendung, während das Fundament stehen bleibt. Die Argumentation dazu haben wir in PHP im AI-Zeitalter ausgeführt.
Wann sich ein Neubau rechnet
Nicht jeder wacklige Prototyp gehört ersetzt. Ausschlaggebend ist allein, ob die fachliche Logik des Produkts sich bereits bewährt hat.
Für einen Rebuild spricht es, wenn das Produkt inhaltlich funktioniert und nachweislich Nutzer findet, während die Probleme im Betrieb liegen, also bei Zugriffsrechten, Datentrennung, Ausfallsicherheit oder Nachvollziehbarkeit. Dann dient der Prototyp als erster Test und als Vorlage der Spezifikation. Er zeigt, was wirklich gebraucht wird.
Gegen einen Rebuild spricht es, wenn das Produkt sich fachlich noch bewegt. Ist zu erwarten, dass die Kernfunktion in den nächsten Monaten mehrfach umgeworfen wird, gießt man besser kein stabiles Fundament darunter. Dann bleibt Weiterbasteln die richtige Wahl, so unbefriedigend das klingt. Gleiches gilt bei überschaubarem Nutzerkreis ohne sensible Daten.
Der häufigste Fehler liegt dazwischen: Teams bauen neu, während sie gleichzeitig noch Funktionen suchen. Sie bezahlen dann für Stabilität, die sie im nächsten Quartal wieder einreißen.
Fazit
KI-Werkzeuge haben die Eintrittshürde gesenkt, die Anforderungen an produktionsreife Software bleiben dieselben. Wird dieser Unterschied erkannt, kann die Strategie sinnvoll ausgerichtet werden. Der praktikable Weg verläuft dabei in beide Richtungen. Prototypen taugen weiterhin dazu, eine Idee zu prüfen, solange allen klar bleibt, dass es Prototypen sind. Und hat sich eine Idee bewährt, liefert der Prototyp die Vorlage für den Neubau.
Sollten Sie unsicher sein, auf welcher Seite dieser Entscheidung Ihr Projekt steht: Sprechen Sie uns an. Wir sehen uns den Stand an und sagen Ihnen, welchen Weg wir empfehlen.
