Technische MVP-audit: wat we in de eerste 48 uur controleren

De meeste MVP-audits leveren een document op. Een nuttige levert beslissingen op: wat brandt, wat kan wachten en wat het kost om het te herstellen.

Een technische MVP-audit beantwoordt één vraag: kan deze codebase de komende twaalf maanden van het bedrijf dragen, en zo niet, wat moet er precies veranderen? Al het andere — tooling-voorkeuren, stijldiscussies, frameworkkeuze — is ruis.

Dit is de checklist die we in de eerste 48 uur doorlopen. Ze is bewust geordend op kosten van falen: wat bovenaan staat kan een bedrijf om zeep helpen, wat onderaan staat kost snelheid.

1. Integriteit van geld en data (hoogste faalkosten)

Beweegt het product geld of houdt het gereguleerde data vast, dan komt dit eerst. Fouten hier zijn geen incidenten — het zijn verplichtingen. We kijken naar:

• Of saldi worden afgeleid uit een append-only grootboek, of worden opgeslagen als een muteerbaar getal dat code kan overschrijven
• Idempotentie op elk betaal- en webhookpad — kan een herhaald verzoek twee keer afschrijven of bijschrijven?
• Gebruik exacte decimalen of gehele ondereenheden met valutaregels.
• Transactiegrenzen: kan een gedeeltelijke storing geld dubbel of nergens achterlaten?
• Reconciliatie: bestaat er een proces dat een afwijking opmerkt, of hoor je het van een klant?

2. Beveiliging en toegangscontrole

• Autorisatie serverseitig gecontroleerd bij elk verzoek, of aangenomen omdat de interface de knop verbergt
• Secrets in omgevingsvariabelen en een secrets manager, niet in de repo-historie
• PII en kaartgegevens: wat wordt opgeslagen, waar, en of dat überhaupt zou moeten
• Werkelijk bereikbare kwetsbaarheden in dependencies, niet alleen een rood getal in een rapport
• Multi-tenant isolatie: kan een vervalst verzoek de data van een andere klant lezen?

3. Architectuur en schaallimieten

We zoeken geen elegantie. We zoeken de concrete muur waar het systeem tegenaan gaat, en hoe ver die weg is.

• De single points of failure — de database, de queue, de service die iedereen aanroept
• Querypatronen die kloppen bij 1.000 rijen en fataal zijn bij 1.000.000 (N+1, ontbrekende indexen, onbegrensde scans)
• Of er zonder downtime uitgerold kan worden, en of iemand het ooit geprobeerd heeft
• Koppeling die verhindert dat je één feature oplevert zonder vijf modules aan te raken
• Of de architectuur past bij de teamgrootte — microservices met vier engineers zijn een schaalprobleem, geen oplossing

4. Oplevering en operatie

Codebases verslechteren niet vanzelf; het proces bepaalt hoe snel. Wat we meten:

5. Technische schuld: getrieerd, niet opgesomd

Elke codebase heeft schuld. Een lijst ervan is nutteloos. Wat telt is de indeling in drie bakken:

1. Blokkerend — verhindert de roadmap of zet geld/data op het spel. Nu oplossen.
2. Cumulatief — maakt elke toekomstige wijziging trager. Bewust inplannen.
3. Cosmetisch — stoort de smaak, kost niets. Met rust laten.

Het doel van een audit is niet alles vinden wat mis is. Het is de paar dingen vinden die erg genoeg zijn om ertoe te doen, en precies zijn over wat ze kosten.

Wat je aan het eind zou moeten krijgen

• Een geprioriteerde lijst bevindingen met ernst en business-impact — geen catalogus
• Per bevinding: de oplossing, een realistische inschatting en wat er gebeurt als je niets doet
• Een gefaseerde roadmap: dit kwartaal, volgend kwartaal, later
• Bewijs — de query, het endpoint, de exacte regel — zodat je team kan verifiëren in plaats van geloven

Maak van de eerste review toetsbaar vervolgwerk

Een begrensde review beschrijft dekking, niet volledige afwezigheid van fouten. Elke bevinding moet controleerbaar zijn.

1. Koppel de getroffen route aan bewijs en reproductievoorwaarden.
2. Scheid waargenomen fouten, vermoedelijke risico's en ontoegankelijke delen.
3. Geef elke oplossing een eigenaar en regressietest.

• MVP herstellen →
• kapot MVP herstellen →