Technische due diligence voor een digitale productherbouw: wat je moet onderzoeken en waarom het ertoe doet

De drang om opnieuw te beginnen is begrijpelijk. Een bestaand digitaal product dat knarst en piept, een codebasis die niemand meer durft aan te raken, een datamodel dat bij elke nieuwe feature tegenwerkt. Herbouwen voelt als de schone lei. Maar zonder technische due diligence loop je het risico om dezelfde problemen opnieuw te bouwen, alleen duurder en met een langere vertraging.

Bij Livewall doen we dit onderzoek altijd voordat we een scale-up ontwikkeltraject of herbouw overnemen. Niet omdat we van documentatie houden, maar omdat we zonder dit inzicht geen eerlijk prijskaartje kunnen hangen en geen realistische planning kunnen maken.

Wat kost het je als je het overslaat?

De verborgen kosten zitten zelden in de code zelf. Ze zitten in wat er omheen is gebouwd:

Verborgen afhankelijkheden. Integraties met externe systemen die nergens gedocumenteerd zijn. Diensten waarop tientallen functies stilletjes leunen. Vervang je een component zonder dit te weten, dan breek je dingen op plekken waar je het niet verwacht.

Datamigratie-complexiteit. Een datamodel dat organisch is gegroeid bevat inconsistenties, dubbele records en verouderde structuren. Als je dit niet in kaart brengt voor de herbouw begint, leidt het tot vertraging op het meest onhandige moment: vlak voor lancering.

Compliance-schuld. AVG-kwesties, toegankelijkheidseisen, verouderde authenticatiemethoden. Deze zitten soms diep in de architectuur verwerkt en zijn niet zomaar opgelost met een nieuwe frontend.

Integratieaannames. Systemen die werken omdat ze op een bepaalde manier zijn gekoppeld, niet omdat die koppeling goed is ontworpen. Herbouw je zonder deze aannames bloot te leggen, dan neem je ze mee naar het nieuwe systeem.

Waar je naar kijkt

Een goede technische due diligence kijkt naar vijf dingen:

1. Architectuur. Is het systeem modulair of verstrengeld? Kun je onderdelen vervangen zonder alles te raken?
2. Afhankelijkheden. Welke externe diensten, bibliotheken en API-koppelingen zijn er? Welke zijn verouderd of niet meer actief onderhouden?
3. Testdekking. Wat is er geautomatiseerd getest? Zonder tests is refactoren gevaarlijk blind.
4. Deployproces. Hoe gaat code van ontwikkeling naar productie? Handmatige stappen zijn risico's.
5. Datamodel. Klopt de structuur nog met hoe het product wordt gebruikt? Waar zitten de grootste migratie-uitdagingen?

De uitkomst van dit onderzoek zijn geen aanbevelingen voor de lange termijn. Het zijn concrete outputs: een risicoregister, een aanbeveling voor herbouwen versus refactoren, en een realistische scope met eerlijke aannames over doorlooptijd en kosten.