Technology due diligence has a reputation as a box-ticking exercise: a firm is hired, a report arrives, everyone nods, the deal proceeds on the terms it was always going to proceed on. That version is real and it is a waste of money.
The version worth paying for answers one question: what would we be buying, and what would it cost us to keep it running? Everything below is in service of that. The checklist matters, but the checklist is not the point — three findings do most of the work, and a diligence exercise that surfaces none of them has probably not looked hard enough.
What a real checklist covers
The scope varies with the deal, but the areas do not. A technology due diligence that skips any of these has a gap someone will find later, at a worse time.
- Architecture and its actual state — not the diagram, the deployed reality. Where they disagree is itself a finding.
- Ownership of the code and the data. Who wrote it, under what agreement, and what licenses came in with it.
- The people. Who knows how it works, how many of them there are, and what their notice periods look like.
- Security posture and history. Not just controls in place — incidents, disclosures, and how they were handled.
- Third-party dependencies. Every vendor in the critical path, with its contract term and its replaceability.
- Deferred maintenance. What has been put off, for how long, and what the deadline is when it stops being optional.
- Whether it scales the way the model assumes. The financial model has a growth curve in it. The system either supports that curve or it does not.
That list is unremarkable, which is the point. Most firms will cover it. What separates a useful diligence from a decorative one is what it does when something in there comes back wrong.
The three findings that most often change the number
1. One person is the system
This is the most common material finding in mid-market technology diligence and the one most reliably underweighted, because it does not look like a defect. Everything works. The system is stable. There is simply exactly one person who understands why.
It shows up in small ways — a deployment process nobody else has run end to end, a service account in someone's name, a set of decisions with no written rationale — and it is a valuation issue rather than an engineering one, because the asset being bought is partly a person who has not signed anything.
The right question is not “is the documentation good?” Documentation is easy to produce badly on request. The question is: when did somebody other than that person last do this? If the honest answer is never, the concentration is real regardless of what is written down.
2. The code is not entirely theirs to sell
Two versions of this, and they are different problems.
The first is contractor work with no assignment of rights. A capable freelancer built a meaningful component years ago under a contract that never transferred ownership, and everybody has behaved ever since as though it did. This is usually fixable and usually awkward, and the cost is time and goodwill rather than money.
The second is license contamination: a dependency whose terms do not permit the way the business uses it. Copyleft in a distributed product is the textbook case, but the modern version is quieter — a model license with a field-of-use restriction, or terms that prohibit using outputs to train a competing system. These sit deep in a dependency tree, they do not announce themselves, and they matter more now that so many systems have model providers in the critical path.
Worth asking directly: has anyone ever produced a full dependency inventory with licenses attached — not a package list, an inventory with terms read? If the answer is that it would take a while, that is the finding, and it is a cheap one to close before a buyer finds it for you.
3. A roadmap that is actually a repair bill
The third finding is a reading exercise rather than a technical one. Take the product roadmap and the engineering backlog, and separate the items that add capability from the items that restore capability the system used to have or was always assumed to have.
When a meaningful share of the next four quarters is the second kind — a platform version that goes out of support, an authentication method being retired, a database that has to move — then the roadmap is not a growth plan. It is maintenance with a growth plan's cover sheet, and the revenue projections attached to it are assuming engineering capacity that is already committed.
This one changes numbers more quietly than the other two. Nothing is broken and nobody is hiding anything. The work is simply already spoken for, and the model does not know it.
What a clean result actually looks like
Clean does not mean no findings. A diligence that returns no findings has told you about the diligence, not the company.
Clean means the findings are known. Somebody inside the business could have written the list themselves, has a view on which items matter, and can say what each one would cost to close. That is a well-run technology function with normal amounts of debt, which is every technology function. The bad outcome is not a long list — it is a short list produced by a company that was surprised by all of it.
If you are the one being diligenced
The asymmetry is worth naming: the buyer's advisors will find these things. Finding them first converts a negotiating lever into a disclosed and priced item, which is a materially better position even when the underlying facts are identical.
In practical order, and none of it needs to wait for a process to start: get somebody other than the key person to run the critical procedures once, and write down what happened. Produce the dependency inventory with licenses read. Split the roadmap into capability and repair, honestly, and put a number against the repair half. Then read the result as though you were buying.
Where this work sits
Technology due diligence is labour and judgement. There is no product here and no license key — the platforms in question stay in whoever's name they are already in, and what is being bought is time from people who have looked at enough systems to know which findings move a number and which ones just fill a page.
It is the same shape as the rest of the fractional CIO work: senior technical judgement, bought by the engagement rather than the headcount, applied to a decision that is expensive to get wrong.
Related reading: Legacy modernization without a rewrite — what to do about the repair half of the roadmap once diligence has separated it out. And AI agent security risks — the credential is the boundary, on why a service account in one person’s name is a finding rather than a detail. If you are reading your own estate rather than someone else’s, start with what a useful IT assessment contains.