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.
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.