Retten oder neu bauen: Was tun mit einer mit KI gebauten Codebasis?

Gründungsteams stellen diese Frage meist nach dem dritten Fix, der zwei andere Dinge kaputt gemacht hat. Dann fühlt es sich nach einem Neubau an, weil niemand den Code mehr nachvollziehen kann. Dieses Gefühl ist nicht die Antwort. Nach unserem Urteil sind die meisten es wert, gerettet zu werden, und die Entscheidung hängt an ein paar Dingen, die sich prüfen lassen. Deshalb treffen wir sie im Audit, schriftlich, bevor irgendeine Arbeit bepreist wird.

Die Zeichen, die für eine Rettung sprechen

• Das Produkt funktioniert, und Menschen nutzen es. Nutzer, Daten und Gewohnheiten sind der teure Teil eines Produkts. Eine Rettung erhält alle drei.
• Das Datenmodell trägt. Sie können die Hauptdinge benennen, um die es im Produkt geht (Konten, Bestellungen, Buchungen, was immer es bei Ihnen ist), und jedes liegt an einem Ort, mit Beziehungen, die Sinn ergeben. Tabellen lassen sich aufräumen; ein Modell, dessen Form stimmt, muss nicht ersetzt werden.
• Die Probleme liegen in den Lücken, die eine Demo nie zeigt. Offenliegende Schlüssel, Endpoints, die jeder aufrufen kann, fehlende Validierung, keine Tests, kein Staging, kein Rollback, kein Monitoring. Das ist ernst, aber nichts davon ist ein Grund, von vorn anzufangen. Es ist Arbeit, die ausgelassen wurde, und ausgelassene Arbeit lässt sich nachholen.
• Die Fehler sind lokal. Ein Fix macht etwas in der Nähe kaputt, nicht etwas am anderen Ende des Produkts.

Die Zeichen, die für einen Neubau sprechen

• Das Datenmodell kann das nächste Feature nicht tragen. Dasselbe ist auf drei Arten an drei Orten gespeichert, oder die Form passt nicht dazu, wohin das Produkt geht: gebaut für einen Nutzer, wenn die Roadmap Teams braucht, oder für einen Verkäufer, wenn sie einen Marktplatz braucht. Jedes Feature ab diesem Punkt wird gegen das Modell gebaut statt darauf.
• Die Berechtigungen lassen sich nicht ausdrücken. Wer was sehen und ändern darf, ist über die Oberfläche verstreut, statt an einem Ort durchgesetzt zu werden, und eine neue Rolle bedeutet, alles anzufassen.
• Das Framework kämpft gegen das Produkt. Das Werkzeug hat einen Stack für die Demo gewählt, und das Produkt braucht etwas, das er schlecht kann: Arbeit, die nach Zeitplan auf einem Server läuft, Zahlungen mit Webhooks, große Datenmengen, eine mobile App. Jeder Workaround kostet mehr als der letzte.
• Niemand kann sagen, wofür der Code da ist. Nicht unordentlich, das ist Code meistens, sondern widersprüchlich: zwei Umsetzungen derselben Regel, die sich nicht einig sind.

Der Mittelweg

Oft ist die Antwort keins von beiden. Die Teile einer mit KI gebauten App, die sich nicht zu retten lohnen, sind meist das Datenmodell und die Berechtigungen, und die lassen sich innerhalb einer Rettung neu bauen: ein neues Modell und eine neue Auth-Schicht, mit migrierten Daten, während die Screens, die Abläufe und der größte Teil des Codes drumherum bleiben. Das Produkt steht nicht still, die Nutzer behalten ihre Konten, und der Teil, der jedes künftige Feature blockiert hätte, wird einmal und richtig ersetzt.

Das ist die Antwort, die wir am häufigsten geben, wenn das Modell falsch ist, aber das Produkt richtig.

Was jede Variante kostet

	Rettung	Modell und Auth innerhalb einer Rettung neu bauen	Neubau
Wann es passt	Das Produkt funktioniert, und Menschen nutzen es; der Code darunter ist das Risiko	Das Produkt stimmt, das Datenmodell oder die Berechtigungen nicht	Das Modell, die Berechtigungen oder das Framework können das nächste Feature nicht tragen, und das Audit sagt es
Geld	Stabilisierung ab $10k; eine vollständige Rettung $20k bis $50k, bepreist nach dem Audit	Als Teil der Rettung bepreist, nach dem Audit	Meist mehr als eine Rettung, aber weniger als eine Rettung, die auf halbem Weg zum Neubau wird
Zeit	Tage zum Stabilisieren, Wochen zum Härten, während die Roadmap weiterläuft	Innerhalb der Rettung, in Schritten	Ein zweiwöchiger Produkt-Sprint, dann ein schneller Build von unter zwei Monaten oder ein explorativer Build von zwei bis vier
Was Sie behalten	Das Produkt, die Nutzer, die Daten und den größten Teil des Codes	Das Produkt, die Nutzer, die Daten und den Code rund um das Modell	Die Produktidee, die Nutzer und die Daten; der Code beginnt neu

Zwei Dinge zur Spalte Neubau. Ein Neubau ist ein Build und wird genauso bepreist: ein Festpreisangebot am Ende des Sprints, aus einem vereinbarten Umfang. Und er geht nicht schnell, nur weil die erste Version schnell ging. Unsere eigenen mehrseitigen Builds, AnyoneGroup und CachePay, dauerten jeweils sechs Monate mit vier Personen; AnyoneGroup begann mit einem klickbaren Prototyp und schriftlichen Beschreibungen, wie sich alles verhalten sollte. Eine funktionierende, mit KI gebaute App gibt einem Neubau mehr als das: die Screens, die Abläufe und das, was Nutzer tatsächlich damit getan haben. Das Backend wird dadurch nicht kürzer.

Es gibt eine vierte Option: so weitermachen. Sie passt zu einem Prototyp, einem internen Werkzeug oder allem, worauf noch keine echten Nutzer oder kein echtes Geld liegen. Heute kostet sie nichts; die Rechnung kommt später, als Datenleck, als Ausfall oder als Neuschreiben unter Druck.

Wie wir im Audit entscheiden

Das Audit liest die Architektur, das Datenmodell, Authentifizierung und Berechtigungen, Secrets, Abhängigkeiten, Testabdeckung und Deployment. Die Entscheidung kommt aus einer Handvoll Fragen:

1. Funktioniert das Produkt für die Menschen, die es jetzt nutzen?
2. Kann das Datenmodell die nächsten drei Dinge auf der Roadmap tragen, ohne verbogen zu werden?
3. Lässt sich jede Berechtigung, die das Produkt braucht, an einem Ort durchsetzen?
4. Passt das Framework zu dem, was das Produkt als Nächstes tun muss, nicht zu dem, was die Demo tun musste?
5. Ist es günstiger, das Bestehende zu reparieren, als es zu ersetzen, wenn man die Nutzer und Daten mitzählt, die ein Neubau umziehen muss?

Ja auf alle fünf heißt Rettung. Ein Nein bei der zweiten oder dritten, mit Ja bei den anderen, heißt meist Mittelweg. Ein Nein bei der vierten und fünften heißt Neubau.

Die eine Regel

Das Audit sagt, was zutrifft, bevor jemand für eines von beiden bezahlt. Es ist kostenlos und schriftlich und liegt innerhalb von 24 Stunden vor. Die Befunde sind danach geordnet, was zuerst kaputtgeht, und am Ende steht eine klare Antwort zu Refactoring oder Neubau und was beides kostet. Wenn ein Neuanfang günstiger ist als die Rettung, erfahren Sie das, bevor Sie etwas ausgeben, und der Bericht gehört Ihnen, ob Sie uns beauftragen oder nicht.