A technical due diligence checklist that is not a formality
Most checklists in circulation ask whether something exists. Is there a test suite. Is there documentation. Is there a disaster recovery plan. Every one of those can be answered yes by a company in serious trouble.
A checklist worth the time asks whether the artifact is true. That is a different exercise, it takes longer, and it produces findings that change valuations rather than filling a folder.
The version below is what I work through in a technical due diligence engagement, organised by what each item is actually testing.
Can the thing be rebuilt without the current team
Clone the repository onto a clean machine and run it. Not a demo — a build from the documented instructions. Time it. If it takes more than a day, or requires someone to answer questions, the documentation is aspirational.
Check whether the deployment is reproducible. Ask to see the last deploy and the one before. If deployment involves a person following steps, the process lives in a head.
Look for infrastructure defined as code. Where the servers were configured by hand, recovering from a serious failure is an archaeology exercise.
Are the tests measuring anything
Read the tests before reading the coverage number. Coverage measures which lines executed, not whether anything was asserted. A suite can execute everything and assert almost nothing.
Find the last three failures in the build history. If the build has been green for a year, either the code is excellent or the tests do not catch regressions. The commit history usually tells you which.
Ask what is deliberately not tested, and why. A team that can answer this crisply understands its own risk. A team that says everything is tested has not thought about it.
What happens when it breaks
Ask for the last three incidents and what changed afterwards. The interesting part is not the incident, it is whether anything structural changed. Repeated incidents with the same root cause indicate the fix is always tactical.
Check whether anyone would know. Monitoring that alerts on server metrics but not on business outcomes will stay silent while orders quietly stop being processed.
Who can be paid, and who can leave
Map the dependencies to their licences. Copyleft in a proprietary product is an occasional and expensive surprise, and it is cheap to check.
Establish the bus factor per subsystem. Not for the company — per subsystem. The answer is frequently one, and the useful follow-up is what that person would need to hand over.
Check who owns the accounts. Domains, cloud, app stores, certificates. Ownership sitting in a departed founder’s personal account is more common than it should be and blocks transactions.
Where the data actually is
Find every copy of production data. Including the ones in analytics tools, support systems and somebody’s laptop. The security posture of a system is the posture of its weakest copy.
Check that backups restore. A backup that has never been restored is a belief, not a control. Ask for the date of the last restore test.
How to use this
Score each item as verified, claimed, or unknown — not pass and fail. The value of the exercise is in the distinction between what you checked and what you were told, and that distinction is what an acquirer or a board is actually paying for.
Findings then sort into three buckets: things that change the price, things that become conditions, and things that are simply worth knowing. Most findings are the third kind, and reporting them as though they were the first is how diligence gets a reputation for theatre.
What to do with an uncomfortable answer
A finding is not automatically a problem. The useful next question is what it would cost to change and what happens if nobody does.
A bus factor of one on a subsystem nobody has touched in two years is a note. The same finding on the billing engine is a condition. Identical technical fact, different weight, and the difference is business context rather than engineering.
That is also the honest answer to teams who feel judged by this list. Almost every company fails several items. The exercise is not a grade — it is establishing which failures are load-bearing for the decision being made, and most of them are not.
What a checklist cannot do
It cannot tell you whether the architecture is right for where the business is going, because that requires knowing where the business is going. It also cannot detect a team that is competent but demoralised, which is a genuine transaction risk and one that no artifact reveals.
I would rather say that plainly than imply the list is complete. It covers what is checkable. The rest is judgement, and judgement should be labelled as such in the report.
Related reading: the diligence process covers the sequence and how long each stage takes, IT due diligence covers the infrastructure and licensing side, and what a report contains covers how findings get written up so they survive a negotiation.