In short
- Code quality is the least important finding in most technical due diligence. The risks that change a valuation are operational.
- Deployment frequency and lead time reveal more about an engineering team than static analysis.
- Key-person dependency is the most common material finding: if one name answers every question, it is a valuation issue.
- Check running costs and their trend, when disaster recovery was last tested, and whether the system does what customer contracts promise about data.
Most technical due diligence reports lead with a code quality assessment. It is the easiest thing to measure and rarely the thing that matters. Untidy code that deploys reliably and is understood by six people is a considerably safer asset than elegant code only one person can change.
Can they release on a Wednesday afternoon?
Deployment frequency and lead time tell you more about an engineering organisation than any static analysis will. Teams that release daily have automated testing, reversible deployments and genuine confidence in their system. Teams that release quarterly, at a weekend, with a rollback plan written in a document, have accumulated risk they may not have priced.
How many people could rebuild this?
Key-person dependency is the most common material finding and the most frequently understated. The questions to ask are practical: who has deployed to production in the last quarter; who understands the billing logic; what happens if the original architect resigns during the earn-out. If one name answers every question, that is a valuation issue rather than an engineering note.
What does it cost to run, and is that going up?
- Cloud spend per customer, and the direction of that trend
- Licence commitments and renewal dates, particularly auto-renewing ones
- Technical debt with a compounding carrying cost, such as an unsupported framework version
- Whether cost is attributable to a team, or arrives as one undifferentiated monthly figure
Would it survive an incident?
Ask when the disaster recovery plan was last actually tested. An untested restore procedure is a hypothesis, not a control. Ask for the last three post-incident reviews. Their absence usually means either genuine stability or an organisation that does not examine its failures, and it is worth knowing which.
Untidy code that deploys reliably is a safer asset than elegant code only one person can change.
Where does the data sit, and who has agreed to what?
Data residency, sub-processor lists, retention policy and the gap between what customer contracts promise and what the system actually does. This gap is common, and it is materially expensive to close after completion because it usually requires renegotiating with customers rather than only changing software.
The question that reveals most
Ask the engineering team what they would fix if given a clear quarter. A team with a considered, prioritised answer understands its own system. A team that cannot answer, or answers with a rewrite, is telling you something important about how well the asset is understood by the people responsible for it.
Common questions
What does technical due diligence look for?
Beyond code quality: how often and safely the team releases, how many people understand the system, running costs and their trend, whether disaster recovery has been tested, and whether data handling matches what customer contracts promise.
What is key-person risk in technical due diligence?
The risk that one person is the only one who can deploy, understands critical logic such as billing, or holds the architecture. If they leave during an earn-out, the asset may be worth much less than it appears.
Written by the Voxalone team. If this raised a question about your own systems, get in touch — you will get a straight answer from an engineer, with no obligation attached.