Een kapotte MVP repareren (zonder opnieuw te beginnen)

Vrijwel elke oprichter met een kapotte MVP vraagt of herschrijven moet. Vrijwel altijd is het antwoord nee — en de reden is rekenkunde, geen sentiment.

Een kapotte MVP laat zich meestal op een van drie manieren zien: hij bezwijkt onder echt gebruik, elke wijziging breekt iets anders, of de oorspronkelijke ontwikkelaars zijn weg en niemand begrijpt hem. Het instinct zegt: opnieuw beginnen. Dat instinct is duur en meestal fout.

Waarom de herschrijving een val is

Herschrijven lijkt aantrekkelijk omdat het nieuwe systeem denkbeeldig is, en denkbeeldige systemen hebben geen bugs. In werkelijkheid:

• De bestaande code bevat jaren aan randgevallen die niemand documenteerde — ze worden herontdekt als productie-incidenten
• Je bevriest featureontwikkeling maandenlang terwijl concurrenten dat niet doen
• De herschrijving loopt tegen dezelfde complexiteit aan, omdat de complexiteit in het domein zit, niet in de code
• Schattingen voor herschrijvingen zitten er ruim naast, consistent, in elke organisatie

Stap 1: stelp de bloeding

Maak het systeem eerst observeerbaar en herstelbaar voordat je iets verbetert. Je kunt niet repareren wat je niet ziet, en niet experimenteren zonder weg terug.

1. Error tracking, zodat storingen bekend zijn in plaats van door klanten gemeld
2. Uptime- en kerntransactiemonitoring — afrekenen, aanmelden, betalen
3. Een rollback die werkt en getest is
4. Back-ups, en een restore die daadwerkelijk één keer is uitgevoerd

Stap 2: trieer, inventariseer niet

Weersta de neiging alles op te sommen wat mis is. Sorteer problemen op gevolg:

De meeste reddingsopdrachten vinden twee of drie punten in de eerste categorie en een handvol in de tweede. Dat is een behapbaar werkprogramma — heel anders dan de verpletterende indruk die het team had voordat de zaken gesorteerd waren.

Stap 3: repareer in de volgorde die zich opstapelt

1. Data-integriteit eerst — beschadigde of verloren data is onherstelbaar op een manier waarop downtime dat niet is
2. Dan het deploypad — zolang uitbrengen niet veilig en frequent is, gaat elke andere fix traag en riskant de deur uit
3. Dan de grootste bron van storingen — meestal veroorzaken één of twee endpoints of queries de meeste incidenten
4. Dan de wijzigingsblokkade — de koppeling of ontbrekende testdekking waardoor het team bang is iets aan te raken
5. Pas daarna performance en afwerking

Stap 4: voorkom terugval

• Tests op de paden die pijn doen — geld, authenticatie en precies datgene wat stukging
• Een geschreven besluitenlogboek, zodat de volgende engineer redenering erft en niet alleen code
• Een deployproces dat iedereen in het team kan uitvoeren
• Een expliciete regel dat de roadmap onderhoudscapaciteit bevat — anders komt de schuld terug

Een redding is geen opruimactie. Het is een klein aantal gerichte wijzigingen die het systeem van onveilig naar saai brengen — en saai is wat een team weer laat leveren.

Bepaal de reparatiegrens vóór herbouw

Laat zien dat één defecte route stabiel kan worden. Gebruik dat resultaat voor de volgende stap en de vervangingsafweging.

1. Schrijf een regressietest voor het waargenomen defect.
2. Herstel een begrensd deel en controleer aangrenzend gedrag.
3. Vergelijk reparatie en vervanging inclusief migratie en parallel bedrijf.

• MVP herstellen →
• MVP technische audit →