Der Prototyp hat seinen Job erledigt
Ein paar Wochen mit Cursor, Lovable oder Replit, und aus einer Idee ist ein funktionierendes Produkt geworden. Erste Nutzer melden sich an, ein Investor zeigt Interesse, vielleicht steht sogar eine Finanzierungsrunde an. Der Prototyp hat genau das geleistet, wofür er gebaut wurde: zeigen, dass die Idee trägt. Das ist kein kleiner Erfolg, sondern der schwierigste Teil, an dem die meisten Ideen scheitern, bevor sie überhaupt live gehen.
Jetzt beginnt eine andere Phase. Was für einen Prototyp genügt hat, genügt nicht automatisch für echte Nutzerzahlen, ein wachsendes Team oder die Prüfung durch Investoren. Das ist kein Rückschritt und kein Zeichen, dass beim Bauen etwas falsch gemacht wurde. Es ist der nächste logische Schritt, sobald eine Idee sich bewährt hat.
Derselbe Fall, nur früher im Leben des Systems
Bei abi services sehen wir dieses Muster meistens bei Systemen, die über Jahre gewachsen sind, ohne dass die Architektur mitgewachsen ist. Ein MVP, das mit einem KI-Coding-Tool gebaut wurde, ist im Kern derselbe Fall, nur früher im Leben des Systems. Statt Jahren organisch gewachsener Entscheidungen von wechselnden Teams sind es Wochen schneller Entscheidungen von einer Person und einem KI-Tool. Die Ursache unterscheidet sich, das Ergebnis nicht: Annahmen, die für Tempo getroffen wurden, tragen jetzt eine Last, für die sie nie gedacht waren.
Der Unterschied ist der emotionale Ausgangspunkt. Bei einem jahrealten Legacy-System steht oft die Frage im Raum, wer für den heutigen Zustand verantwortlich ist. Bei einem wenige Monate alten MVP stellt sich diese Frage nicht. Es gibt nichts zu rechtfertigen. Schnell und unperfekt zu bauen war die richtige Entscheidung, um die Idee zu testen. Jetzt zu härten ist die richtige nächste Entscheidung, weil sich die Anforderungen geändert haben, nicht weil die erste Entscheidung falsch war.
Was an dieser Stelle üblicherweise nachgeholt werden muss
Vier Dinge tauchen fast immer auf, wenn ein KI-gebautes MVP über den Prototypenstatus hinauswächst. Das Datenmodell wurde für Tempo entworfen, nicht für Korrektheit, also fehlen Constraints, und Zustände, die eigentlich unmöglich sein sollten, kommen trotzdem in der Datenbank vor. Es gibt kaum oder keine automatisierten Tests, weshalb jede Änderung am Code ein Risiko ist, das vorher niemand einschätzen kann. Niemand trägt eine klare Verantwortung für den Code, weil eine Person zusammen mit einem KI-Tool ihn iterativ gebaut hat und selbst diese Person nicht mehr jeden Winkel im Kopf hat. Und es gibt Sicherheitsabkürzungen, offene Endpunkte, großzügige Berechtigungen, fest im Code verankerte Zugangsdaten, die in Ordnung waren, solange nur der Gründer selbst darauf zugegriffen hat, aber nicht mehr, sobald echte Nutzer echte Daten eintragen.
Keiner dieser vier Punkte bedeutet, dass das MVP schlecht gebaut wurde. Sie bedeuten, dass ein System, das für einen Test gebaut wurde, jetzt Anforderungen erfüllen soll, für die es nie gedacht war.
Auch hier gilt: keine Big-Bang-Neuentwicklung
Der naheliegende Reflex ist, das MVP wegzuwerfen und mit einem sauberen Team neu zu bauen. Das ist bei einem wenige Monate alten System genauso riskant wie bei einem zehn Jahre alten. Eine vollständige Neuentwicklung bindet Zeit und Budget, ohne dass in der Zwischenzeit ein neues Feature entsteht, und am Ende steht wieder ein System, das erst in der Praxis beweisen muss, ob es hält.
Der Ansatz, den wir bei Legacy-Modernisierung grundsätzlich verfolgen, passt hier genauso gut: nicht alles auf einmal ersetzen, sondern in Abschnitten härten, die einzeln ausgeliefert werden können. Zuerst die Bestandsaufnahme, welche Annahmen im Code stecken und wo die größten Risiken liegen. Dann der Schnitt, welcher Teil zuerst dran ist, meistens die Sicherheitslücken, weil sie am schnellsten teuer werden. Danach das Datenmodell und die fehlenden Tests, Stück für Stück, während dein Team weiter an neuen Funktionen arbeiten kann. Das MVP bleibt dabei die ganze Zeit über lauffähig, es wird nicht durch etwas Neues ersetzt, sondern von innen tragfähig gemacht.
Was am Ende steht
Am Ende läuft dasselbe Produkt, das deine ersten Nutzer schon kennen, nur auf einem Fundament, das eine Finanzierungsrunde, ein wachsendes Team oder echten Nutzeransturm trägt, ohne dass jede Änderung ein Risiko ist und ohne dass eine einzelne Person der einzige Zugang zum System bleibt.
Wenn du bei einer der vier Fragen von oben zögerst, besonders bei der Frage, wer im Zweifel erklären kann, warum eine bestimmte Stelle im Code so aussieht, wie sie aussieht, ist das ein guter Zeitpunkt für Legacy-Modernisierung, auch wenn dein System erst ein paar Monate alt ist.