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?
De meeste technische due diligence levert een document op dat niemand gebruikt. Het somt frameworks op, telt tests, merkt op dat de documentatie beter kon — en daarna gaat de deal door of niet, om totaal andere redenen. Dat verspilt een echte kans om risico te beprijzen.
Nuttige technische due diligence beantwoordt drie vragen in bedrijfsmatige termen: kan deze technologie het plan dragen dat je financiert, wat kost het om de gaten te dichten, en welke risico's kunnen waarde vernietigen in plaats van alleen vertragen.
Waar technische due diligence werkelijk voor dient
Een venture-investeerder koopt geen codebase. Hij koopt een these: dit team bereikt die schaal in deze periode. Technologie telt alleen daar waar ze die these waarschijnlijker of onwaarschijnlijker maakt.
| De these zegt | Dus moet de diligence vaststellen |
|---|---|
| 10× gebruikersgroei in 24 maanden | Waar de architectuur breekt, en wat het kost dat plafond te verhogen |
| Uitbreiding naar de EU | Of de dataverwerking de AVG overleeft, en wat een conforme versie kost |
| Dit is een betaalbedrijf | Grootboekintegriteit, idempotentie, reconciliatie — de dingen die écht geld verliezen |
| Het team kan uitvoeren | Leverdoorvoer en bus factor, niet de kwaliteit van cv's |
| Verdedigbare technologie | Of de gracht echte engineering is of een dun laagje over andermans API |
De vijf gebieden die ertoe doen
1. Architectuur en schaalruimte
Elk systeem heeft een plafond. De vraag is waar het ligt ten opzichte van het plan, en hoe duur het is om het te verhogen. Een monoliet die 100.000 gebruikers moeiteloos bedient is geen bevinding; een monoliet met één schrijf-master database en een groeiplan naar 10 miljoen wel.
- De single points of failure — en of het team weet welke dat zijn
- De datalaag — meestal het echte plafond en het duurste om later te veranderen
- Of belasting ooit getest is, of dat schaal wordt aangenomen
- Cloudkostencurve: overleeft de unit economics 10×, of eet de infrastructuur de marge op?
2. Integriteit van geld en data
Voor elk bedrijf dat betalingen, saldi of gereguleerde data raakt, is dit het gebied waar fout zitten het duurst is — en het gebied dat het vaakst wordt overgeslagen, omdat inspectie domeinkennis vereist.
- Wordt het saldo afgeleid uit een onveranderlijk grootboek, of is het een muteerbaar getal dat code kan overschrijven?
- Idempotentie op betaal- en webhookpaden — kan een retry dubbel afschrijven?
- Geld opgeslagen als gehele getallen in minor units, nooit als float
- Reconciliatie: zou een afwijking intern worden opgemerkt, of door een klant?
3. Blootstelling aan security en compliance
Securitybevindingen zijn alleen zinvol als ze aan een gevolg hangen. «Dependencies zijn verouderd» is ruis. «Een niet-geauthenticeerd endpoint geeft records van andere tenants terug» is een dealclausule.
- Autorisatie serverseitig afgedwongen per verzoek, niet verstopt in de UI
- Multi-tenant isolatie — veruit de meest voorkomende ernstige bevinding in B2B-SaaS
- Secrets-beheer, en of credentials in de git-historie staan
- Welke gereguleerde data wordt opgeslagen — en of dat überhaupt zou moeten
- Afstand tot de certificering die de go-to-market vereist (SOC 2, ISO 27001, PCI DSS)
4. Leververmogen
Dit voorspelt de komende twee jaar beter dan de huidige codebase. Een middelmatige codebase met sterke leverdiscipline verbetert. Een elegante codebase zonder het vermogen veilig te leveren niet.
- Deployfrequentie en doorlooptijd voor een kleine wijziging
- Of rollback geoefende routine is of theorie
- Testdekking op de paden die ertoe doen (geld, auth) in plaats van een globaal percentage
- Incidentdetectie: vinden ze problemen vóór klanten?
5. Team- en sleutelpersoonrisico
- Bus factor: hoeveel mensen begrijpen de kritieke subsystemen — is het antwoord één, dan is dat dealrisico
- Of kennis buiten hoofden bestaat
- Afhankelijkheid van contractors bij kern-IP, en of de IP-overdracht schoon is
- Realisme van het aannameplan tegenover de gefinancierde roadmap
Rode vlaggen, gerangschikt naar wat ze werkelijk kosten
| Bevinding | Ernst | Waarom |
|---|---|---|
| Muteerbare saldi / geen grootboek in een fintech | Dealniveau | Verliezen zijn onbegrensd en kunnen al onopgemerkt hebben plaatsgevonden |
| Datatoegang tussen tenants | Dealniveau | Eén datalek beëindigt enterprise-verkoop en trekt toezichthouders aan |
| Eén engineer bezit alle kritieke kennis | Hoog | Zijn vertrek zet de roadmap terug |
| Geen deployautomatisering | Hoog | Beperkt doorvoer ongeacht hoeveel je aanneemt |
| Onduidelijk IP-eigendom van contractors | Hoog | Juridisch, niet technisch — maar het doodt exits |
| Verouderde dependencies | Laag | Routineonderhoud, in dagen te beprijzen |
| Inconsistente codestijl | Ruis | Negeren |
Het doel van technische due diligence is niet een reden vinden om af te haken. Het is precies weten wat je koopt, zodat prijs en plan dat weerspiegelen.
Hoe bevindingen dealvoorwaarden worden
- Herstelbudget — de fixes kwantificeren en expliciet in de ronde financieren in plaats van ze in maand zes te ontdekken
- Mijlpaalvoorwaarden — tranchevrijgave gekoppeld aan specifiek herstel (gebruikelijk als compliancegaten de go-to-market blokkeren)
- Waarderingsaanpassing — waar het herstel groot is ten opzichte van de ronde
- Post-closing plan — een technische roadmap van 90 dagen, vóór de overboeking afgesproken en niet erna geïmproviseerd
Hoe lang het duurt
| Diepte | Duur | Wanneer te gebruiken |
|---|---|---|
| Screening | 2-3 dagen | Vroege fase, kleine cheque, alleen een sanity check |
| Standaard | 1-2 weken | De meeste Series A / Series B rondes |
| Diep | 3-4 weken | Fintech, healthtech, grote cheque, of een target dat bekendstaat als rommelig |
Langer is niet beter. Voorbij twee weken produceren de meeste trajecten detail in plaats van beslissingen — tenzij het domein het echt vraagt, zoals betalingen of gereguleerde zorgdata.
Bepaal de scope vóór de documentverzameling
De review moet passen bij de investeringsthese. Definieer vragen, belangrijke systemen en bewijs vóór risicobeoordeling.
- Verbind groeiverwachtingen met capaciteit en operationele kosten.
- Scheid verklaringen, gecontroleerde tests en ontbrekende gegevens.
- Onderscheid voorwaarden vóór overdracht en een gefinancierd vervolgplan.
Veelgestelde vragen
Wat is het verschil tussen technische due diligence en een code-audit?
Een code-audit onderzoekt codekwaliteit. Technische due diligence onderzoekt of de technologie, het team en het leverproces een specifiek bedrijfsplan kunnen dragen — en wat de gaten kosten. Code is één van vijf inputs; architectuur, security, leververmogen en sleutelpersoonrisico wegen doorgaans zwaarder voor het investeringsbesluit.
Wie betaalt de technische due diligence?
Bijna altijd de investeerder, als onderdeel van de transactiekosten. Soms laat een oprichter het vóór de ronde doen om problemen te vinden en op te lossen voordat investeerders dat doen — meestal goed besteed geld, want bevindingen die de tegenpartij ontdekt kosten in onderhandeling veel meer dan in engineering.
Is medewerking van de startup nodig?
Ja. Zinvolle diligence vereist leestoegang tot de repository, een architectuurdoorloop en een gesprek met de engineers. Een target dat zich hiertegen verzet is zelf een bevinding die het noteren waard is.
Kan technische due diligence in een paar dagen?
Een screeningronde wel, en die vangt betrouwbaar problemen op categorieniveau: geen grootboek in een betaalbedrijf, geen deployautomatisering, bus factor van één. Het vertelt je niet wat herstel kost. Voor een geprijsde ronde is één tot twee weken het realistische minimum.
Kan onderzoek doorgaan met beperkte toegang?
Ja, met kleinere scope en expliciete beperkingen. Leg onzekerheid vast en vraag ontbrekend bewijs voordat de conclusie als vastgesteld wordt gebruikt.
Diligence op een portfoliobedrijf?
Wij leveren bevindingen gerangschikt op bedrijfsimpact, met herstelkosten die je mee de onderhandeling in neemt — in één tot twee weken.
Verder lezen
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.
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.