Someone is about to spend money on technology they did not build. They are buying a company, taking over a platform, inheriting a system when a partner leaves, or committing to a build a supplier has already started. At some point in that room a non-technical person asks the only question that matters — is this any good? — and nobody present can answer it.
That question is what technical due diligence exists to answer. It is not an audit, and its output is not a verdict. It is a price and a plan: what you are actually acquiring, what it will cost to keep alive, and what has to be true before you can rely on it.
This is the order I take it in. The order matters more than the checklist, because the cheapest checks are the ones most likely to end the conversation, and there is no sense costing a rebuild you will not be doing.
1. Can somebody else run it
Before anything about code, I establish whether the thing can be operated by a person who is not the person who built it. This takes an afternoon and it settles more deals than any other step.
The list is unglamorous: who owns the domain registrar account, who controls DNS, whose card pays the hosting, who is the administrator on the cloud account, who holds the app store listings, who receives the security alerts, and whose personal email is the recovery address on any of it.
I have seen a functioning business discover that its domain was registered to a freelancer who had stopped answering, and a company whose entire production environment sat inside a former employee’s personal account. Neither was a coding problem. Both were existential, and both were invisible in every document produced up to that point.
If ownership cannot be transferred cleanly, nothing downstream is worth measuring yet.
2. Can it be rebuilt from what exists
The second question is whether the running system can be reproduced from the things you are being given. Not improved — reproduced.
I ask for the repository and then try to start the application from a clean machine, following whatever written instructions exist. The gap between what the instructions say and what actually turns out to be necessary is one of the most honest measurements available. A system that only one laptop can build is a system with one point of failure, and that point is a person.
The twelve-factor methodology is a useful yardstick here, and its middle sections are the ones that matter for diligence: dependencies declared explicitly rather than assumed, configuration held outside the code, backing services treated as attachable resources, and build separated strictly from run. A codebase that satisfies those can be handed over. One that does not will be handed over anyway, and the difference will show up as months.
I also want a list of what is inside it — the third-party libraries and services it depends on, and their licences, which is what a software bill of materials in a format such as SPDX is for. The UK NCSC’s supply chain guidance is blunt about why: you cannot assess a risk you cannot enumerate, and most organisations cannot name their dependencies.
3. What does it cost to stay still
Every system has a standing cost that nobody quotes, because it is spread across invoices that arrive separately.
I total four things: infrastructure, third-party services and licences, the support and maintenance the vendor already charges, and the human time spent keeping it running each month. That last one is almost never on a spreadsheet and is frequently the largest of the four.
The number this produces is the floor. It is what you pay to have the system continue doing exactly what it does today, with nothing added and nothing improved. Buyers routinely model the purchase price and not the floor, which is how a cheap acquisition becomes an expensive year.
4. What breaks if it succeeds
Then I ask what happens at ten times the current load. Not because ten times is coming, but because the answer reveals the shape of the thing.
Usually one component is doing far more than its share, and everyone already knows which. The useful part is not discovering it — it is establishing whether the fix is a configuration change, a component swap, or a redesign, because those are three different budgets and three different timelines.
This is also the question a pilot never has to answer, which is one reason so many of them stall on the way to real use — the pattern behind where UAE pilots stop short of production. A system that cannot grow is not automatically a bad buy. A system that cannot grow, sold as one that can, is a different matter, and the gap between those two is worth finding before the price is agreed.
5. What data is in it, and what comes attached
Whatever you are acquiring, you are acquiring its data and the obligations that travel with it. That means knowing what personal data is held, where it physically sits, who has access, how long it is kept, and what was promised to the people it describes.
In this market that is not an abstract question — the federal personal data protection law applies to the records regardless of who owned the system when they were collected, and the same reasoning I set out in what the data protection law asks before you connect a model applies to a system you inherit. Consent obtained for one purpose does not automatically extend to yours.
I also want to know what happens on the day you want to leave. An export that produces a proprietary blob is not an export. The test is whether someone outside the vendor can read the output and reconstruct the records, and the time to run that test is before signing, not during a dispute.
6. Who actually knows how this works
The last question is the one people are most reluctant to ask in front of the seller. How many people understand this system well enough to change it safely, and are any of them staying?
Documentation is not the answer to that question, and I do not weight it heavily. What I look for instead is evidence in the system itself: commit history spread across several people rather than concentrated in one, code that a competent stranger can follow, and tests that fail when something is broken. Those three tell you whether knowledge is distributed or resident in a person who is about to become a consultant at three times their old rate.
This is the same argument as everything else expensive in technology — it is cheap to establish now and costs a multiple later, which is the pattern behind the technology decisions a company pays for twice.
Things that look bad and are not
Some findings frighten buyers and should not.
- An unfashionable stack. A boring, well-understood technology with people available to hire is usually a lower risk than a modern one with three specialists in the country.
- Visible technical debt that is written down. A team that can list what is wrong has been paying attention. Silence is the worrying answer.
- No automated tests on a small internal tool. Proportionate. The absence only matters where change is frequent or failure is expensive.
Things that look fine and are not
- A polished interface over a system nobody can deploy. The demo is the part that was rehearsed.
- Security that consists of a firewall and hope. The OWASP Top 10 exists because the same categories recur; if nobody on the team can discuss where their system sits against it, nobody has looked.
- One heroic engineer who answers everything instantly. That is not strength, it is concentration, and concentration is what you are buying.
- Backups that exist. Backups that have been restored are a different claim, and the NCSC’s guidance on backing up makes the same point: a backup nobody has recovered from is untested. Ask for the date of the last restore, not the last backup.
What the report should say
A diligence report that ends in a grade is not useful. The one I write ends in four things.
- What you are acquiring — the systems, the accounts, the data and the people, listed rather than described.
- What must be fixed before you can rely on it — with a cost and a duration against each, separated from what merely ought to be improved.
- The standing cost — the annual floor from step three, so the business case uses a real number.
- The three things that would change the recommendation — stated plainly, so a decision made against the advice is at least made knowingly.
None of that requires the buyer to be technical. That is the point of the exercise: to convert a question only an engineer can answer into a set of numbers and conditions that a person signing a contract can act on. It is the core of what I do as a fractional CTO, and it is the same discipline underneath treating e-invoicing as a systems project — establish what is actually true about the systems before committing to a date or a price.
Frequently asked questions
How long does technical due diligence take?
For a single system, three to five working days of actual work, spread over a week or two because it depends on other people answering. Anything sold as a one-day review is a document read, not a diligence. Anything running past a month has usually turned into consulting on how to fix what was found, which is a separate engagement and should be priced as one.
What if the seller will not give access to the code?
That is common early and reasonable until terms are agreed. The usual answer is a staged process: interviews and documentation first, then code access under an agreement once the deal is credible. What is not acceptable is signing without it. If access is refused at the point where the deal is otherwise done, treat the refusal as a finding rather than an obstacle.
Can our own developers do this instead?
They can do the technical parts, and often better than an outsider because they know your context. Two things make it awkward. They may end up owning what they assess, which is a difficult position to be objective from. And they will be asked to deliver bad news about a deal their own management wants. That is a lot to put on an employee, and it is most of why the role is usually external.
We are not buying a company, just choosing a supplier. Does this apply?
A reduced version does, and the same order works. Steps one, five and six matter most: whether you will own what is built, what happens to your data, and whether the knowledge stays with you when the relationship ends. Those three answered honestly before signing prevent most of the disputes that arrive two years later.
What single finding most often changes a price?
The standing cost from step three, because it is the one nobody has totalled. A system presented as finished and cheap to run, which turns out to consume a person and a half in maintenance, changes the value of the deal without anything being wrong with the code. Ownership problems from step one end deals more often; the standing cost reprices them more often.