Investeerders geven je code geen cijfer. Ze prijzen het risico dat technologie het plan stopt dat ze financieren — en oprichters die dat begrijpen bereiden zich heel anders voor.
Oprichters die zich voorbereiden op technische due diligence poetsen vaak de verkeerde dingen op — code opruimen, documentatie schrijven waar niemand om vroeg, piekeren over frameworkkeuzes. Investeerders stellen een heel andere vraag: wat kan er misgaan met de technologie waardoor dit bedrijf de mijlpalen in het plan niet haalt?
De vier dingen die werkelijk beoordeeld worden
1. Schaalt het naar het plan (niet naar oneindig)
Niemand verwacht van een Series A-bedrijf de architectuur van Google. De vraag is smaller: overleeft het systeem de specifieke groei in het model, en zo niet, wat kost het dat plafond op te hogen? Een helder, geprijsd antwoord is een sterk signaal. «Het zou goed moeten gaan» is dat niet.
2. Sleutelpersoonrisico
Vaak de meest doorslaggevende bevinding, en degene die oprichters het minst verwachten. Als één engineer alle kritieke kennis draagt, brengt de investering een risico met zich mee dat niets met codekwaliteit te maken heeft. Investeerders vragen er rechtstreeks naar: wie zou dit systeem volgende week kunnen draaien als die persoon vertrekt?
3. Of de technologie werkelijk van jullie is
- Werk van contractors zonder getekende IP-overdracht — een juridisch probleem dat een closing kan vertragen of afblazen
- Licentiebesmetting door open source in een propriëtair product
- Kritieke afhankelijkheid van een leverancier die kan herprijzen, beperken of verdwijnen
- Hoeveel van de «eigen technologie» een dun laagje over andermans API is
4. Leververmogen
Dit voorspelt de komende twee jaar beter dan de huidige staat van de codebase. Investeerders kijken naar deployfrequentie, hoe wijzigingen productie bereiken, of incidenten intern worden gedetecteerd, en of het team de aannames in het plan qua werving aankan.
Hoe je je voorbereidt (in de vier weken ervoor)
- Schrijf een eerlijk technisch risicoregister — wat zwak is, wat het blokkeert, wat herstel kost. Dat uit jezelf aanbieden leest als competentie; betrapt worden op verbergen leest als het tegendeel.
- Repareer eerst alles in de categorie geld en data — dat zijn de bevindingen die dealvoorwaarden worden.
- Dicht IP-gaten: getekende overdrachten van elke contractor, licentiereview van dependencies.
- Verlaag de bus factor zichtbaar — zet iemand extra op het kritieke systeem, schrijf het architecture decision record.
- Bereid een heldere architectuurdoorloop voor: wat het is, waarom, waar het breekt, wat het plan is.
Hoe bevindingen dealvoorwaarden worden
| Bevinding | Typische uitkomst |
|---|---|
| Geld kan stilletjes verkeerd zijn (geen grootboek) | Herstel gefinancierd in de ronde; soms in tranches |
| Datalek tussen tenants | Opschortende voorwaarde — repareren voordat middelen vrijkomen |
| Onduidelijk IP van contractors | Juridische regularisatie vereist vóór closing |
| Bus factor van één | Retentiepakket, of wervingstoezegging in het plan |
| Handmatige deployment, geen rollback | Ingecalculeerd in het 90-dagenplan na closing |
| Verouderende dependencies, dunne documentatie | Genoteerd, zonder gevolg |
Investeerders verwachten geen perfect systeem. Ze verwachten een oprichter die precies weet welke delen onvolmaakt zijn en wat het kost die te repareren.
Verbind elke bevinding aan een beslissing
Maak duidelijk welke aannames standhouden en wat het plan verandert. Toon onzekerheid naast herstelwerk.
- Noem de bedrijfsaanname en onderzocht bewijs.
- Beschrijf gevolg, onzekerheid en herstelafhankelijkheden.
- Scheid overdrachtsvoorwaarde, budgetpost en geaccepteerd risico.
Veelgestelde vragen
Hoe lang duurt technische due diligence van een investeerder?
Doorgaans één tot twee weken voor een Series A, langer bij fintech, healthtech of ongewoon grote systemen. Het omvat meestal repositorytoegang, een architectuurdoorloop en gesprekken met het engineeringteam.
Moeten oprichters zelf een technische audit doen vóór het ophalen?
Vaak wel. Bevindingen die je zelf boven tafel haalt worden een herstelplan dat jij beheerst; dezelfde bevindingen via de adviseur van de investeerder worden een onderhandelingspositie tegen je. De kosten van een audit vooraf zijn klein ten opzichte van de waarderingsimpact die het kan voorkomen.
Kan rommelige code onze ronde om zeep helpen?
Zelden op zichzelf. Deals worden beïnvloed door bevindingen met gevolg — geldintegriteit, securityblootstelling, onduidelijk IP-eigendom en sleutelpersoonrisico. Investeerders hebben de onvolkomenheden van elke codebase gezien; wat hen zorgen baart is een team dat de eigen risico's niet accuraat kan beschrijven.
Is één technische score voldoende?
Nee. Een score vat samen maar verbergt scope en onzekerheid. Voeg belangrijke bevindingen, ontbrekend bewijs en ramingsaannames toe.
Binnenkort aan het ophalen?
Wij doen de diligence vóór je investeerder — zodat de bevindingen met jouw herstelplan erbij komen.
Verder lezen
Technische due diligence voor investeerders: de complete gids
Technische due diligence is geen code review. Het is het antwoord op één vraag: wat kost het om deze technologie te brengen waar de investeringsthese haar nodig heeft?
Code-audit vóór investering: wat je moet vragen voordat je overmaakt
Je staat op het punt een aandeel te kopen in een bezit dat je niet hebt geïnspecteerd. De code-audit is die inspectie — maar alleen als hij is afgebakend op investeringsvragen in plaats van engineeringvragen.