Fast jeder Gründer mit einem kaputten MVP fragt, ob man es neu schreiben soll. Fast jedes Mal lautet die Antwort nein — und der Grund ist Arithmetik, nicht Sentimentalität.
Ein kaputtes MVP zeigt sich meist auf eine von drei Arten: Es bricht unter echter Nutzung zusammen, jede Änderung zerstört etwas anderes, oder die ursprünglichen Entwickler sind weg und niemand versteht es. Der Instinkt sagt: neu anfangen. Dieser Instinkt ist teuer und meist falsch.
Warum der Rewrite eine Falle ist
Der Rewrite wirkt attraktiv, weil das neue System imaginär ist — und imaginäre Systeme haben keine Bugs. In der Realität:
- Der bestehende Code kodiert Jahre von Sonderfällen, die niemand dokumentiert hat — sie werden als Produktionsvorfälle wiederentdeckt
- Sie frieren die Feature-Entwicklung für Monate ein, während die Konkurrenz es nicht tut
- Der Rewrite trifft auf dieselbe Komplexität, denn die Komplexität liegt in der Domäne, nicht im Code
- Schätzungen für Rewrites liegen deutlich daneben, konsistent, in jeder Organisation
Schritt 1: Blutung stoppen
Bevor Sie irgendetwas verbessern, machen Sie das System beobachtbar und wiederherstellbar. Man kann nicht reparieren, was man nicht sieht, und nicht experimentieren ohne Rückweg.
- Error Tracking, damit Fehler bekannt sind statt von Kunden gemeldet
- Uptime- und Schlüsseltransaktions-Monitoring — Checkout, Registrierung, Zahlung
- Ein Rollback, der funktioniert und getestet wurde
- Backups, und ein Restore, der tatsächlich einmal durchgeführt wurde
Schritt 2: Triagieren, nicht inventarisieren
Widerstehen Sie dem Drang, alles Fehlerhafte aufzulisten. Sortieren Sie Probleme nach Konsequenz:
| Kategorie | Definition | Maßnahme |
|---|---|---|
| Blutend | Verliert gerade jetzt Geld, Daten oder Kunden | Diese Woche beheben |
| Blockierend | Verhindert die Roadmap des nächsten Quartals | Dieses Quartal beheben |
| Kumulierend | Macht jede Änderung langsamer | Bewusst einplanen |
| Kosmetisch | Beleidigt den Geschmack, kostet nichts | Nie |
Die meisten Rettungsmandate finden zwei oder drei Punkte in der ersten Kategorie und eine Handvoll in der zweiten. Das ist ein überschaubares Arbeitsprogramm — ganz anders als der erdrückende Eindruck, den das Team davor hatte.
Schritt 3: In der Reihenfolge beheben, die sich verstärkt
- Datenintegrität zuerst — beschädigte oder verlorene Daten sind auf eine Weise unwiederbringlich, wie Ausfallzeit es nicht ist
- Dann der Deployment-Pfad — solange Releasen nicht sicher und häufig ist, wird jeder andere Fix langsam und riskant ausgeliefert
- Dann die größte Fehlerquelle — meist verursachen ein oder zwei Endpunkte oder Queries die meisten Vorfälle
- Dann der Änderungsblocker — die Kopplung oder fehlende Testabdeckung, die das Team davor zurückschrecken lässt, etwas anzufassen
- Erst dann Performance und Feinschliff
Schritt 4: Rückfall verhindern
- Tests auf den Pfaden, die wehtun — Geld, Auth und genau das, was kaputtging
- Ein schriftliches Entscheidungsprotokoll, damit der nächste Entwickler Begründungen erbt, nicht nur Code
- Ein Deployment-Prozess, den jeder im Team ausführen kann
- Eine ausdrückliche Regel, dass die Roadmap Wartungskapazität enthält — sonst kommt die Schuld zurück
Eine Rettung ist kein Aufräumen. Sie ist eine kleine Zahl gezielter Änderungen, die das System von unsicher zu langweilig bringen — und langweilig ist das, was ein Team wieder liefern lässt.
Vor einer Neuentwicklung die Reparaturgrenze bestimmen
Zeigen Sie zunächst, dass sich ein fehlerhafter Ablauf stabilisieren lässt. Daraus den nächsten Abschnitt und den Vergleich zur Ablösung ableiten.
- Den beobachteten Fehler durch einen Regressionstest absichern.
- Einen begrenzten Bereich reparieren und angrenzende Abläufe prüfen.
- Reparatur und Ersatz einschließlich Migration und Parallelbetrieb vergleichen.
Häufige Fragen
Sollen wir unser MVP neu schreiben oder reparieren?
Reparieren, es sei denn, die Plattform ist nicht mehr betreibbar, das Produkt hat sich grundlegend verändert, oder das ganze System lässt sich in wenigen Wochen neu bauen. Rewrites frieren Feature-Arbeit für Monate ein, entdecken vergessene Sonderfälle als Produktionsvorfälle wieder und überziehen ihre Schätzungen konsistent.
Wie lange dauert eine MVP-Rettung?
Die Triage dauert Tage. Die Stabilisierung der kritischen Punkte typischerweise zwei bis sechs Wochen je nach Schweregrad. Die vollständige Sanierung kumulierender Schuld dauert ein Quartal oder mehr — läuft aber neben der Feature-Arbeit statt an ihrer Stelle.
Unsere ursprünglichen Entwickler sind weg. Ist der Code noch zu retten?
Fast immer. Die Autoren zu verlieren macht die Arbeit langsamer, nicht unmöglich: Die erste Aufgabe ist zu rekonstruieren, wie sich das System tatsächlich verhält — durch Lesen, Instrumentierung und Characterization Tests — bevor irgendetwas geändert wird.
Woran erkennen wir, ob unser MVP wirklich kaputt oder nur unperfekt ist?
Fragen Sie, ob es Geld oder Daten verliert, ob es die Roadmap blockiert und ob das Team Angst vor dem Deployen hat. Trifft nichts davon zu, haben Sie ein unperfektes MVP — das ist normal und keinen Eingriff wert.
Wann sollte neue Funktionsentwicklung pausieren?
Wenn laufende Änderungen Diagnose oder Datenintegrität gefährden. Umfang der Pause und die notwendigen Nachweise für eine Wiederaufnahme ausdrücklich festlegen.
MVP in Schwierigkeiten?
Wir triagieren in Tagen und sagen Ihnen ehrlich, ob es eine Rettung, einen Rewrite oder gar nichts braucht.
Weiterführend
Technisches MVP-Audit: Was wir in den ersten 48 Stunden prüfen
Die meisten MVP-Audits produzieren ein Dokument. Ein nützliches produziert Entscheidungen: Was brennt, was kann warten, und was kostet die Behebung.
Technische Schulden im Startup: Wie viel ist zu viel?
Jedes Startup hat technische Schulden, und die meisten davon waren die richtige Entscheidung. Die Frage ist nicht, wie man sie beseitigt — sondern welche Teile Zinsen verlangen, die Sie sich nicht mehr leisten können.