Een checklist is alleen nuttig als aan elk punt een gevolg hangt. Deze is geordend op wat een deal daadwerkelijk verandert.
Eigendom en afhankelijkheden
Product en beheer
Herstel en beslissing
Gebruik dit als werkdocument tijdens de diligence. Elke sectie vermeldt wat je opvraagt, wat je verifieert en — cruciaal — wat een slecht antwoord commercieel betekent. De punten staan geordend op kosten van fout zitten, niet op gemak van controleren.
Voordat je begint: wat je opvraagt
- Leestoegang tot alle repositories, inclusief infrastructure-as-code
- Volledige commit-historie (geen platgeslagen momentopname — historie onthult wie dit werkelijk bouwde en hoe snel)
- Architectuurdoorloop met de engineer die het bouwde, 1-2 uur
- Toegang tot de issue tracker en eventuele incidentverslagen
- Lijst van externe diensten en hun contractvoorwaarden
- Contractorovereenkomsten en documenten voor IP-overdracht
Sectie 1 — Integriteit van geld en data (dealniveau)
| Controle | Een slecht antwoord betekent |
|---|---|
| Saldi afgeleid uit een append-only grootboek? | Geld kan stilletjes verkeerd en onherstelbaar zijn — herstel financieren of weglopen |
| Idempotency keys op elk betaalpad? | Retries kunnen dubbel afschrijven; verliezen kunnen al onopgemerkt bestaan |
| Geld opgeslagen als gehele getallen in minor units? | Floating-point rekenwerk stapelt fouten op bij elke transactie |
| Reconciliatie tegen de settlement van de provider? | Afwijkingen komen via klantklachten boven |
| Onveranderlijk audittrail incl. adminacties? | Vragen van toezichthouders of bij geschillen niet te beantwoorden |
Sectie 2 — Security en tenancy (dealniveau)
- Autorisatie serverseitig afgedwongen bij elk verzoek, niet door UI-elementen te verbergen
- Multi-tenant isolatie geverifieerd met een test, niet aangenomen op basis van codelezen
- Secrets in een manager, afwezig uit de git-historie (controleer de historie, niet alleen HEAD)
- Welke gereguleerde data wordt opgeslagen, waar, en of dat nodig is
- Afstand tot de certificering die de go-to-market vereist (SOC 2, ISO 27001, PCI DSS)
Sectie 3 — Eigendom en juridisch (dealniveau)
- Getekende IP-overdracht van elke contractor en oprichter
- Open-source licentiereview — copyleft-besmetting in een propriëtair product
- Code gekopieerd van vorige werkgevers (vraag het rechtstreeks; het gebeurt)
- Vendor lock-in: wat breekt als een kernleverancier herprijst of stopt
Sectie 4 — Architectuur en schaal (hoog)
- Waar het systeem breekt onder de groei in het financiële model — een concreet getal, geen geruststelling
- Het plafond van de datalaag: één schrijf-master, onbegrensde queries, indexdekking tegen echte querypatronen
- Faalisolatie: escaleert één trage afhankelijkheid tot een volledige storing
- Infrastructuurkostencurve bij 10× — overleeft de unit economics
- Architectuur passend bij de teamgrootte (gedistribueerde systemen met een klein team zijn een kostenpost, geen keurmerk)
Sectie 5 — Leververmogen (hoog)
| Signaal | Gezond | Zorgelijk |
|---|---|---|
| Deployfrequentie | Meerdere keren per week | Maandelijks, ingepland, gevreesd |
| Doorlooptijd kleine wijziging | Uren tot een dag | Weken |
| Rollback | Eén commando, geoefend | Nooit getest |
| Incidentdetectie | Interne monitoring | Meldingen van klanten |
| Tests op geld-/authpaden | Aanwezig | Afwezig ongeacht de totale dekking |
Sectie 6 — Team en sleutelpersoonrisico (hoog)
- Bus factor van elk kritiek subsysteem — is die ergens 1, dan is dat dealrisico dat mitigatie vraagt
- Of kennis op schrift bestaat of alleen in hoofden
- Retentieblootstelling: wie zou catastrofaal zijn om de komende 12 maanden te verliezen
- Realisme van het wervingsplan dat de roadmap veronderstelt
Scoren: gevolg, geen smaak
Scoor elke bevinding op wat er gebeurt als die niet wordt opgelost, en laat dat de dealreactie sturen:
- Dealniveau — geldintegriteit, datablootstelling, onduidelijk IP. Opschortende voorwaarde of gefinancierd herstel.
- Hoog — schaalplafond onder het plan, afhankelijkheid van één persoon, geen deployveiligheid. Ingecalculeerd in het 90-dagenplan na closing.
- Midden — cumulatieve schuld die de levering vertraagt. Noteren en volgen.
- Ruis — stijl, frameworkvoorkeur, documentatievolume. Volledig uit het rapport laten.
Als een bevinding niet aan geld, tijd of juridische blootstelling te koppelen is, hoort ze niet in een investeringsmemo.
Waarop je in het eindrapport staat
- Een samenvatting van één pagina waarop een niet-technische partner kan handelen
- Elke bevinding met bewijs dat het team van het target zelfstandig kan verifiëren
- Herstelschattingen in engineer-weken, zodat ze naar geld te vertalen zijn
- Een expliciete vermelding van wat NIET is onderzocht — zodat niemand dekking veronderstelt die er niet was
Maak van de checklist een besluitdocument
Elke reactie moet naar bewijs en een transactiegevolg verwijzen. Spreek grenzen, toegang en vragen vooraf af. Scheid geverifieerde bevindingen, managementverklaringen en ontbrekend bewijs. Een leeg vak is geen bewijs van laag risico.
| Maak de beslissing meetbaar | Spreek vooraf het bewijs af |
|---|---|
| Eigendom en afhankelijkheden | Vraag repositoryhistorie, bijdragersovereenkomsten en afhankelijkheden op. Juridisch advies toetst de rechten. |
| Product en beheer | Volg een belangrijk gebruikerspad, toets uitrol en herstel en vergelijk architectuur met groeiaannames. |
| Herstel en beslissing | Koppel eigenaar, inspanning, afhankelijkheid en verificatie aan bevindingen. Scheid voorwaarden vooraf van werk na de transactie. |
Het rapport benoemt onderzoek, onbekenden en mogelijke gevolgen. Documentonderzoek bewijst niet op zichzelf dat productiecontroles werken; technische review is geen juridische certificering.
Veelgestelde vragen
Wat hoort er in een checklist voor technische due diligence?
Zes gebieden, op volgorde van gevolg: integriteit van geld en data, security en tenantisolatie, IP-eigendom, architectuur en schaalruimte, leververmogen en sleutelpersoonrisico. Elk punt hoort een benoemd commercieel gevolg te hebben — een checklist zonder gevolgen levert rapporten op waar niemand naar handelt.
Welk punt wordt het vaakst gemist?
IP-overdracht van contractors. Het is geen technische vraag, dus technische reviewers slaan het over en juristen nemen aan dat engineering het heeft gedekt. Het heeft bovendien de langste doorlooptijd om op te lossen, en hoort daarom in de eerste dagen gecontroleerd te worden en niet in de laatste.
Kunnen oprichters deze checklist zelf gebruiken?
Ja, en vóór een ronde is dat een goed idee. Bevindingen die je zelf ontdekt worden een herstelplan dat jij beheerst; dezelfde bevindingen ontdekt door de adviseur van een investeerder worden een onderhandelingspositie tegen je.
Liever laten uitvoeren door iemand die het wekelijks doet?
Wij leveren diligence met bevindingen gerangschikt op bedrijfsgevolg en herstel geprijsd in engineer-weken.
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?
Waar VC's echt op letten bij technische due diligence
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.