ยท 6 min read
Technical due diligence in the Benelux: what sets the price.
You are about to price a company whose main asset is software you have not read, built by people you have not met. Technical due diligence in the Benelux is the two weeks that close that gap: an independent CTO reads the code, meets the team, pulls the real delivery data, and hands back the risks priced in euros. Most of the value is in three findings, and each of them should move the number.
What the two weeks actually cover
A technical diligence is not a code-quality opinion. It answers one question for a buyer: can this company do, at this price, what the deck says it will do. To answer it, five things get read.
- The code and the architecture. Whether it can carry the growth in the plan, and what breaks first when it does.
- The team and the key people. Who actually built this, who can maintain it, and how much of the company leaves if one person does.
- The real delivery cadence. What the team ships per quarter, read from the repository history, not the roadmap.
- The cost trend. What the platform costs now and at projected traffic, and whether the curve bends up faster than revenue.
- The contracts. The supplier and licence terms that reprice or bite the day control changes hands.
All five matter. But in engagement after engagement, the same three findings are the ones that reach the price, so start there.
The three findings that should move the price
One: the company lives in one or two heads. The most common finding, and the most expensive to miss. The system that runs the business was written by a small number of people, often the two who started it, and almost nothing is written down. Read the commit history and the shape is plain: two of fifteen engineers wrote most of the code that matters. That is not a talent compliment. It is key-person risk, and it means a large part of what you are buying can resign in its notice period. This moves the price through retention terms, an earn-out that keeps the right people in the building, or a discount if it cannot be secured. Either way it changes the number, and it belongs on page one.
Two: the real cadence is slower than the roadmap. The deck promises monthly releases and a feature list for the next year. The repository shows one real release a quarter and a backlog that has not moved. The gap between the two is the growth case, and the growth case is what you are paying a multiple for. If the plan needs twice the delivery the team has ever produced, either the plan is wrong or the hiring it silently assumes is not in the model. Both change what the company is worth today, because the upside you underwrote assumes delivery the team has not shown.
Three: a cost or a contract that scales against you. Sometimes the platform is fine and the margin is not, because the cost curve climbs faster than revenue and nobody owns it. The same lens from the cloud cost work applies: the waste is usually an ownership gap, not a pricing one, and it survives the deal unless someone names it. Then there are the contracts. A licence that reprices on change of control, an agency that holds the deployment keys, a single supplier the product cannot run without. Each one is a liability that belongs in the model next to the technical debt priced per month, not discovered in the first quarter after close.
What the report gives you
A written report inside two weeks. The risks priced in euros, the deal-breakers separated from the negotiation points, and a 100-day plan for the technology if the deal goes through. The distinction matters more than the list. A deal-breaker kills the deal or resets the price. A negotiation point is something you now know and the seller does not know you know. A finding with no number attached is an opinion, and opinions do not survive a data room. If the platform will not carry the plan you are paying for, the report says so on the first page, not in an appendix.
What this is not, and when to skip it
This is technical diligence, not financial or legal diligence. It reads the software, the team, and the delivery. It does not read the books or the cap table, and it does not replace a lawyer on the share purchase agreement or an M&A advisor on the structure. Call those people for those jobs. A good technical report makes their work sharper, because it turns "the tech seems fine" into a priced list they can put in the same model.
Skip it when there is nothing bespoke to buy. If the target runs on an off-the-shelf ERP it does not modify and a public website, the software is not the asset and a light review is enough. Skip the deep version for a pure acqui-hire where you are buying the team, keeping them, and would pay the same whatever the code looks like. Everywhere else, when the software is the reason for the deal, two weeks of reading before you sign is the cheapest part of the transaction. It is exactly the work the technical due diligence practice is built for.
Frequently asked
Who does technical due diligence for a software acquisition in the Benelux?
An independent engineering leader who has run and rebuilt software teams, not a generalist audit firm. For a deal in Belgium, the Netherlands, or Luxembourg, that means a CTO who reads the target's code, meets the people who wrote it, and pulls the delivery data from the repositories, then returns a written report inside two weeks with the risks priced in euros and the deal-breakers separated from the negotiation points. It is a different job from financial or legal diligence and runs alongside them, not instead of them.
What does a technical due diligence actually check?
Five things. The code and architecture, and whether they can carry the growth in the deck. The team and the key people, meaning who really built this and how much of the company walks out if one person does. The real delivery cadence, read from the repository history rather than the roadmap. The cloud cost trend at current and projected traffic. The supplier and licence contracts that reprice or bite after a change of control. Each finding is stated plainly and, where it costs money, priced.
How long does technical due diligence take, and what does it cost?
Five to eight working days of the reviewer's time, with the written report inside two weeks of getting access. The fee is fixed, from EUR 6 500, set by the size of the target and agreed before the work starts. Sell-side preparation, getting your own company ready for a buyer's diligence, uses the same checklist at the same fee.
What is the difference between technical and financial due diligence?
Financial diligence reads the books: revenue quality, margins, working capital. Technical diligence reads the asset you are actually buying when the asset is software: the code, the people who maintain it, and the pace at which they ship. A financial model can look clean while the platform underneath it cannot carry the plan the model assumes. You need both, and they answer different questions.
Written from patterns I've seen across engagements. If any of it sounds too specific to be general, that's why.