Technical due diligence

You are buying a business. Along with it you are buying its code.

The financials will be shown to you and audited. The system will be shown too — from the seller's side, by the seller's people, in the seller's presentation. And you will be paying for it for years, with the first bill arriving before you have hired your own team.

The code gets read, not the story about it. It is the only source with no interest in the deal. Documentation describes the intention, the presentation describes the hope, the code describes the fact.

The first year of ownership gets costed. Not "code quality" — a judgement you cannot put on a negotiating table — but money: how many people it takes for this simply to keep running, and how many more for it to change.

What cannot be bought separately gets found. People without whom the system is not maintained. Third-party components out of support. Data that lives in one place and does not move.

Expensive gets separated from fatal. Expensive is a price and can be written into the deal. Fatal is what makes the system untransferable; there are usually one or two such findings, and they change the whole negotiation.

It is urgent. This route almost always runs at the rush price: the deal window is shorter than an unhurried reading.

A list of what you are actually buying, and the price of the first year of ownership in people and money. Separately, the findings worth carrying into the price negotiation.

The document is yours and is written so that it can be shown to the other side.

A valuation of the business and its prospects — that is different work and different people.

And there is no verdict on whether to buy. That one is yours, and it is not about the code.

Tell me when the deal window closes and whether there is access to the repository. Everything else follows from those two answers; I do not read systems from presentations.