· 6 min lezen

Technische due diligence in de Benelux: wat de prijs bepaalt.

Je staat op het punt een bedrijf te prijzen waarvan het belangrijkste actief software is die je niet gelezen hebt, gebouwd door mensen die je niet ontmoet hebt. Technische due diligence in de Benelux is de twee weken die dat gat dichten: een onafhankelijke CTO leest de code, ontmoet het team, haalt de echte leveringsdata op, en geeft de risico's terug, geprijsd in euro. De meeste waarde zit in drie bevindingen, en elk daarvan hoort het bedrag te bewegen.

Wat die twee weken echt dekken

Een technische due diligence is geen mening over codekwaliteit. Ze beantwoordt één vraag voor een koper: kan dit bedrijf, tegen deze prijs, doen wat de deck belooft. Om dat te beantwoorden worden vijf dingen gelezen.

Alle vijf tellen mee. Maar opdracht na opdracht zijn het dezelfde drie bevindingen die de prijs raken, dus begin daar.

De drie bevindingen die de prijs horen te bewegen

Eén: het bedrijf leeft in een of twee hoofden. De meest voorkomende bevinding, en de duurste om te missen. Het systeem dat de zaak draait is geschreven door een klein aantal mensen, vaak de twee die begonnen, en bijna niets staat opgeschreven. Lees de commit-historie en de vorm is duidelijk: twee van de vijftien engineers schreven het meeste van de code die telt. Dat is geen compliment over talent. Het is sleutelpersoonsrisico, en het betekent dat een groot deel van wat je koopt kan opstappen binnen de opzegtermijn. Dit beweegt de prijs via retentievoorwaarden, een earn-out die de juiste mensen in huis houdt, of een korting als het niet kan worden vastgezet. Hoe dan ook verandert het het bedrag, en het hoort op pagina één.

Twee: de echte cadans is trager dan de roadmap. De deck belooft maandelijkse releases en een featurelijst voor het komende jaar. De repository toont één echte release per kwartaal en een backlog die niet bewogen is. Het gat tussen die twee is het groeiverhaal, en het groeiverhaal is waar je een multiple voor betaalt. Als het plan het dubbele vraagt van wat het team ooit geleverd heeft, dan is ofwel het plan fout ofwel de aanwerving die het stil veronderstelt niet ingecalculeerd. Beide veranderen wat het bedrijf vandaag waard is, want de meerwaarde die je onderschreef veronderstelt levering die het team niet getoond heeft.

Drie: een kost of een contract dat tegen je schaalt. Soms is het platform in orde en de marge niet, omdat de kostencurve sneller klimt dan de omzet en niemand ze bezit. Dezelfde bril uit het cloudkostenwerk geldt: de verspilling is meestal een eigenaarschapsgat, geen prijsprobleem, en ze overleeft de deal tenzij iemand ze benoemt. En dan zijn er de contracten. Een licentie die herprijst bij controlewissel, een agency die de deploymentsleutels vasthoudt, een enkele leverancier zonder wie het product niet draait. Elk daarvan is een verplichting die in het model hoort, naast de technische schuld geprijsd per maand, niet iets dat je ontdekt in het eerste kwartaal na closing.

Wat het rapport je geeft

Een geschreven rapport binnen twee weken. De risico's geprijsd in euro, de deal-breakers gescheiden van de onderhandelingspunten, en een 100-dagenplan voor de technologie als de deal doorgaat. Het onderscheid telt meer dan de lijst. Een deal-breaker doodt de deal of reset de prijs. Een onderhandelingspunt is iets wat je nu weet en waarvan de verkoper niet weet dat jij het weet. Een bevinding zonder cijfer eraan is een mening, en meningen overleven een dataroom niet. Als het platform het plan niet kan dragen waar je voor betaalt, zegt het rapport dat op de eerste pagina, niet in een bijlage.

Wat dit niet is, en wanneer je het overslaat

Dit is technische due diligence, geen financiële of juridische. Ze leest de software, het team en de levering. Ze leest de boeken of de cap table niet, en ze vervangt geen advocaat op de overnameovereenkomst of een M&A-adviseur op de structuur. Bel die mensen voor die jobs. Een goed technisch rapport maakt hun werk scherper, want het maakt van "de tech lijkt in orde" een geprijsde lijst die ze in hetzelfde model kunnen zetten.

Sla het over als er niets op maat te kopen valt. Draait het doelwit op een standaard ERP die het niet aanpast en een publieke website, dan is de software niet het actief en volstaat een lichte review. Sla de diepe versie over bij een pure acqui-hire waar je het team koopt, het houdt, en hetzelfde zou betalen ongeacht hoe de code eruitziet. Overal elders, wanneer de software de reden voor de deal is, is twee weken lezen voor je tekent het goedkoopste deel van de transactie. Het is net het werk waar de praktijk voor technische due diligence voor gemaakt is.

Veelgestelde vragen

Wie doet technische due diligence bij een software-overname in de Benelux?

Een onafhankelijke engineeringleider die software-teams heeft geleid en herbouwd, geen generalistisch auditkantoor. Voor een deal in België, Nederland of Luxemburg betekent dat een CTO die de code van het doelwit leest, de mensen ontmoet die ze schreven, en de leveringsdata uit de repositories haalt, en dan binnen twee weken een geschreven rapport teruggeeft met de risico's geprijsd in euro en de deal-breakers gescheiden van de onderhandelingspunten. Het is een andere job dan financiële of juridische due diligence en loopt ernaast, niet in de plaats.

Wat controleert een technische due diligence precies?

Vijf dingen. De code en de architectuur, en of ze de groei uit de deck kunnen dragen. Het team en de sleutelmensen: wie het echt bouwde en hoeveel van het bedrijf naar buiten wandelt als één persoon dat doet. De echte levercadans, gelezen uit de repository-historie in plaats van de roadmap. De kostentrend van het platform bij huidig en verwacht verkeer. De leveranciers- en licentiecontracten die herprijzen of bijten bij een controlewissel. Elke bevinding staat er klaar, en waar ze geld kost, geprijsd.

Hoe lang duurt technische due diligence en wat kost ze?

Vijf tot acht werkdagen van de reviewer, met het geschreven rapport binnen twee weken na toegang. De prijs ligt vast, vanaf EUR 6 500, bepaald door de grootte van het doelwit en afgesproken voor het werk start. Sell-side voorbereiding, je eigen bedrijf klaarmaken voor de due diligence van een koper, gebruikt dezelfde checklist tegen hetzelfde tarief.

Wat is het verschil tussen technische en financiële due diligence?

Financiële due diligence leest de boeken: kwaliteit van de omzet, marges, werkkapitaal. Technische due diligence leest het actief dat je echt koopt wanneer dat actief software is: de code, de mensen die ze onderhouden, en het tempo waaraan ze leveren. Een financieel model kan er proper uitzien terwijl het platform eronder het plan niet kan dragen dat het model veronderstelt. Je hebt beide nodig, en ze beantwoorden verschillende vragen.


Geschreven vanuit patronen uit eerdere opdrachten. Als iets te specifiek klinkt om algemeen te zijn, is dat de reden.