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.
Een code-audit vóór investering valt binnen de bredere technische due diligence en heeft een smallere taak: vaststellen wat er werkelijk is, of het eigendom schoon is en of het het gefinancierde plan kan dragen.
Slecht afgebakend levert het een lijst stijlklachten op. Goed afgebakend levert het twee of drie bevindingen op die de deal veranderen.
Welke toegang je opvraagt
Vraag deze vóór het tekenen van de term sheet. Weerstand in dit stadium is op zichzelf al informatief.
- Leestoegang tot alle repositories — inclusief infrastructure-as-code en deployscripts, waar de werkelijke stand van zaken vaak zichtbaar is
- Volledige commit-historie, geen platgeslagen momentopname: de historie onthult wie het systeem echt bouwde en hoe snel het beweegt
- Een architectuurdoorloop met de engineer die het bouwde, één tot twee uur
- Toegang tot de issue tracker en, waar aanwezig, incidentverslagen
- De lijst van externe diensten waarvan het product afhangt
De acht vragen die de audit moet beantwoorden
- Komt de bestaande code overeen met wat in de pitch is beschreven? (Demoware en integraties die in werkelijkheid handmatige processen zijn, komen vaak voor.)
- Wie schreef het, en zijn die mensen er nog?
- Is het IP-eigendom schoon — contractors onder overdracht, geen ongelicentieerde gekopieerde code, geen licentiebesmetting door GPL-dependencies in een propriëtair product?
- Wat breekt als eerste onder het groeiplan, en wat kost het dat plafond te verplaatsen?
- Zijn klantgegevens geïsoleerd tussen tenants, en wordt autorisatie serverseitig afgedwongen?
- Voor alles wat financieel is: bestaat er een onveranderlijk grootboek, en is elk geldpad idempotent?
- Kan het team veilig deployen — automatisering, rollback, monitoring?
- Hoeveel van het product is werkelijk van henzelf versus een dun laagje over leveranciers die kunnen herprijzen of verdwijnen?
Bevindingen die een dealvoorwaarde rechtvaardigen
| Bevinding | Typisch gevolg |
|---|---|
| Kern gebouwd door contractors zonder IP-overdracht | Afronden vóór overmaken — juridisch, geen technisch middel |
| Geen grootboek in een bedrijf dat geld beweegt | Herstelbudget gefinancierd in de ronde; mogelijk tranching |
| Datalek tussen tenants | Herstel als opschortende voorwaarde |
| Kritieke leveranciersafhankelijkheid zonder terugvaloptie | Concentratierisico gemeld; soms een convenant |
| Bus factor van één op het kernsysteem | Retentiepakket of sleutelpersoonverzekering |
| Geen geautomatiseerde deployment | Ingecalculeerd in het post-closing plan |
Wat je aandacht niet waard is
Auditors die per bevinding factureren geven je een lange lijst. Het meeste doet er voor een investeringsbeslissing niet toe:
- Framework- of taalvoorkeuren — elke keuze heeft critici
- Inconsistente codestijl en formattering
- Laag totaalpercentage testdekking, terwijl de geld- en authpaden gedekt zijn
- Verouderde dependencies zonder bereikbare kwetsbaarheid
- Ontbrekende documentatie — echt gebruikelijk, zelden doorslaggevend, goedkoop te herstellen
Als het auditrapport niet in drie zinnen aan je investeringscommissie is samen te vatten, is het afgebakend als een engineeringoefening in plaats van een investeringsvraag.
Hoe een goede oplevering eruitziet
- Een samenvatting van één pagina in bedrijfstaal, met een duidelijke totale risicopositie
- Bevindingen gerangschikt op gevolg, elk met bewijs dat het team van het target kan verifiëren
- Herstelkosten in engineer-weken, zodat het naar geld te vertalen is
- Een aanbevolen technisch 90-dagenplan na closing
- Een expliciete lijst van wat NIET is onderzocht, zodat niemand dekking veronderstelt die er niet was
Leg vast welk bewijs je inkoopt
De koper moet een belangrijke bevinding naar de bron kunnen volgen en begrijpen wat handelen kost.
- Identificeer repository, commit, omgeving en reviewdatum.
- Vraag voorbeelden, getroffen routes en inspanningsaannames.
- Vereis uitsluitingen en een mogelijkheid voor hercontrole.
Veelgestelde vragen
Hoe lang duurt een code-audit vóór investering?
Drie tot tien werkdagen voor de meeste seed- en Series A-targets. Fintech, healthtech of ongewoon grote codebases duren langer. Voorbij twee weken koop je meestal detail in plaats van beslissingen.
Weet de startup dat we ze auditen?
Ja — een zinvolle audit vereist repositorytoegang en engineertijd, dus het is een coöperatief proces. Serieuze targets verwachten het en voelen zich er doorgaans prima bij; ongebruikelijke weerstand is op zichzelf het noteren waard.
Kun je auditen zonder toegang tot broncode?
Alleen oppervlakkig. Zonder repository kun je het draaiende product, de publieke securityhouding en teamsignalen beoordelen, maar niet de zuiverheid van het IP, de echte architectuur of de onderhoudbaarheid — en dat zijn meestal de bevindingen die ertoe doen.
Wat als de audit ernstige problemen vindt?
Dat is een geslaagde audit, en het beëindigt de deal zelden. De meeste bevindingen worden een herstelbudget, een opschortende voorwaarde, gefaseerde financiering of een waarderingsaanpassing. De echte misser is dezelfde problemen in maand zes ontdekken, als ze veel meer kosten.
Heeft de auditor een productiedatabase nodig?
Niet standaard. Gebruik bij voorkeur synthetische of passend opgeschoonde gegevens en beperkte toegang. Verruim alleen voor een concrete anders onbeantwoordbare vraag.
Audit nodig voordat je overmaakt?
Bevindingen gerangschikt op bedrijfsgevolg, herstel geprijsd in engineer-weken, geleverd binnen twee 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?
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.