Technical due diligence: the buyer takes on your problems too

On the other side of the table at Gridky sat the acquirer’s CEO, the group CTO and firms paid to find risks. Nobody there was looking for beautiful code. They wanted to know who can deploy, who wrote what and under which contract, how the business would restart after a major incident, and which licence obligations were hidden in the dependencies. On the seller’s side, what struck me was how much the examination revealed about our own knowledge of the product.

Because the buyer is also taking on people and risks, and the technical file exists to prove you know what you are selling. The seller who knows negotiates. The one who discovers the answers during the review loses control of the negotiation.

I did the exercise on the seller’s side as Head of Engineering at Gridky, acquired by Groupe Premium, then at another company where the sale fell through: it was profitable, the offers did not measure up, and it had no reason to sell itself short. Both times, preparation took about a month. Those were sales; a funding round brings similar scrutiny, with the depth depending on the investor.

The buyer wants to understand which people the product’s operation depends on. Technical interviews help establish whether the team can explain the architecture, past decisions and deployment procedures. When only one person holds that knowledge, their departure creates a difficulty that the documentation also needs to help assess.

What comes out of the CVs and the interviews is not a grade, it is a map of who holds what. Developers talk about the bus factor; the buyer says “key person”, with an owner’s anxiety.

In the deals I have known, contracts were reissued in the acquirer’s name for employees and freelancers alike. Renewing a freelancer’s contract can open a negotiation, particularly when that person holds knowledge that is hard to transfer. I would rather know in January who will hold the cards in June than discover it pen in hand. In France, when Article L1224-1 of the Labour Code applies, existing employment contracts pass to the new employer without renegotiation. The consequences depend on the structure of the deal and should be examined with your counsel.

The review also covers ownership of the code. For every contractor who contributed to the product, the contract needs to be found and its rights assignment provisions checked. Technical due diligence gathers the information: who wrote what and under which contract. Legal assessment belongs to the advisers handling the deal.

I remember the surprise: a component installs in one line, then years later you have to explain to the audit firm what that line commits you to. I called it a primed bomb in the value chain. Establishing the actual obligations then means reading the licence and examining the integration.

Open source does not mean free of obligations. Permissive licences, MIT, BSD and Apache 2.0, include requirements to retain copyright notices and the licence text. Copyleft licences add redistribution obligations. As the GNU Project explains, copyleft requires anyone who redistributes the software, with or without changes, to pass on the freedom to copy and modify it. A product sold to customers that incorporates a GPL component may therefore be required to provide its own source code under the same licence to those who receive it. The scope of that obligation requires a legal assessment of the integration.

SaaS use also calls for licence checks. The AGPL specifically addresses interaction over a network. According to Wikipedia, it requires that the source code of modified versions be “prominently offered to all users who interact with the software over a network”.

The inventory therefore needs to show where and how each component is used: as a build tool, a library incorporated into the product or a separately operated service. This gives a specialist lawyer the information needed to examine the applicable obligations before the buyer’s review.

A buyer does not want to inherit a system full of security holes or a lawsuit waiting to happen. By taking over the company, they take over its risks, and they know it better than you do: it is their job. Hence three questions they always ask.

Compliance first. At a minimum the GDPR and data sovereignty: where the data is hosted, who can access it, which jurisdiction each supplier answers to. They are not asking you to be perfect. They are asking you to know.

Security next. They want to see the measures in place, past incidents and what you did about them. This is where sellers pick the wrong strategy: they hide. A weakness that is known, documented and being fixed can be defended. A weakness their firm discovers on its own casts doubt on the rest of the file, including the parts that were true.

Continuity last. A written recovery procedure does not convince them; a backup restore that was actually performed, with its date and how long it took, does.

And then there is what nobody thinks to show: the debt, and the manual chores. The buyer prefers a debt you describe, with an order of magnitude, to a debt they guess at by reading the code; the first becomes a project, the second a pricing argument. As for the manual tasks, the reminder run by hand every week, the export only one person knows how to produce, the certificate renewal noted in a diary, they appear in no documentation and stop the day that person leaves. They are part of what is being bought; the buyer needs to know they exist.

The same roadmap can push the price up or pull it down.

For a mature asset expected to generate stable revenue, the buyer will examine maintenance costs and the investment still needed. If they want a company that can scale, they will want to understand how the roadmap supports that growth. A major feature can be justified in either case: show which objective it serves, the resources required and the funding assumptions.

Most SME roadmaps I have read are wish lists. In front of a buyer, a wish list turns against you, because it contradicts what you say about your debt and your resources three tabs later. A due diligence roadmap is judged on its consistency with the rest of the file, not on its ambition. The page on roadmap and product trade-offs explains how to build priorities that pass that test.

A month, both times. Not because the documents are numerous, but because they do not exist in a form an outsider can read. You have to go through every repository to recover the licence of every dependency. You have to cross-check billing, open accounts and the integrations present in the code to establish the list of suppliers, because none of those three sources is complete on its own (the method is detailed in Our CTO has left). You have to write documentation a stranger will understand, then check it against the real product.

And that month lands on the shoulders of those who ship, fix and answer incidents. The same people, always. The only preparation that costs little is the one that started earlier, in the form of three inventories kept up as you go.

The list of dependencies can be extracted from each project’s files, with the licence each one declares: this is what CISA calls an SBOM, an inventory of the components that make up a piece of software. Extraction is the easy part. The work starts afterwards: spotting the licences a lawyer needs to read, the components abandoned by their authors, the paid software whose contract is in a person’s name rather than the company’s.

For each supplier: who holds the account, who pays, what data it receives, how to leave it. A supplier present in the billing but absent from your list is a red flag, and the buyer immediately wonders what else is missing. An incomplete inventory flagged as such can be defended; an inventory presented as exhaustive and then disproved costs you your credibility on everything else. A tool removed from the product often leaves an account or a key behind: The access that outlives the tools shows how to check that it is really gone.

CVs do not describe a team. A knowledge map, linking each part of the system to the people able to work on it, does, and it shows where knowledge is concentrated, which is to say where the buyer will negotiate. Documentation covers the architecture, deployment, operations and the structural choices with their reasons. It tells the truth: documentation written for the occasion, which contradicts the code, casts doubt on everything.

A coverage figure on its own is a number for reassuring a board. It measures the code the tests execute, not the relevance of what they check. Present it with the areas covered, the areas not covered, and the reason. Same rule for an availability rate: without scope or method, a good number looks cherry-picked. Describe your debt yourself; the article on the cost of technical debt gives one way to put an order of magnitude on it. And never write “the product is secure and monitored”. Show the alerts, who receives them, and the incidents tracked.

A folder full of PDFs can still be impossible to review. I want to start from a claim, find its evidence and understand what is missing. To prepare that review on the seller’s side, I would build a map like this. It is a preparation aid, rather than an audit firm’s contractual checklist.

Question to examine	Supporting material	What still needs explaining
What technical assets are being acquired?	Product map, repositories, architecture and integrations	Scope covered, external dependencies and poorly documented areas
Who can keep the product running?	Knowledge map, procedures and company access records	Reliance on one person and handover work still needed
Which components and suppliers do we use?	Dated inventories, licences, contracts and billing records	Discrepancies between sources and points for the advisers to examine
How do we recover after an incident?	Procedure, latest restore test report and incident records	What was actually tested, its scope and what remains untested
What will the product need next?	Roadmap, known debt and workload assumptions	Funded decisions, dependencies and remaining uncertainty

For each item, I would record an owner, a date and a scope. A missing document stays marked as missing. An old document keeps its original date: renaming it “final version” does not update its contents.

Take a fictional finding: a restore procedure exists, but no test report has been supplied. The evidence supports saying that the procedure is written. It does not support saying that recovery works, or claiming how long it takes. The next action is to agree a test with the operations owner and retain its result. I would rather see that incomplete line than a green indicator with nothing behind it: at least everyone knows what still needs checking.

“We are certified.” “We have a continuity plan.” Good, but I would still ask for the licences, the knowledge map and a backup restore someone has actually performed. Those pieces answer different questions.

According to ISO, ISO/IEC 27001 defines the requirements for an information security management system. It addresses security risk management. Examining licences, code maintainability and the team’s knowledge requires further information.

According to the French SGDSN guide published in 2013, a business continuity plan sets out the strategy and measures intended to allow an organisation to resume and continue its activities after a disaster or serious disruption. It documents preparation for those situations, with a purpose distinct from reviewing the code.

The technical and organisational diagnostic I offer can help prepare for a deal by identifying risks and priorities across architecture, debt, delivery and the team. Its scope remains specific: I am not commissioned by the buyer, and those five days replace neither licence and supplier inventories nor an exhaustive code audit.

The Gridky sale went through. The other failed on price. I do not attribute either outcome to the technical file; a file does not sell a company. It does something else that matters as much: it decides who leads the conversation. The seller who knows their people, their licences and their debt talks as an equal with the firm across the table. The one who discovers them during the review answers questions, and every hesitation becomes a pricing argument.

Without waiting for a deal, six inventories are enough to avoid turning up empty-handed:

1. extract each project’s dependencies and their licences
2. cross-check the supplier list against billing
3. list the contractors who wrote code and check that their rights were assigned
4. draw up the team’s knowledge map
5. test a backup restore, noting its date and duration
6. list the recurring manual tasks

If you do not do it, someone will do it for you, paid by the buyer, while your team still has a roadmap to deliver. The page on technical governance describes what a managing director needs to be able to follow so that these inventories exist without a crisis, and the Gridky case study tells the company’s technical context and the stabilisation work carried out with the team.