Technical due diligence: what it costs, what it covers and when to commission one

01What a real due diligence covers

Code quality and test coverage, architecture and scalability limits, security posture, dependency and licence exposure, infrastructure cost trajectory, team structure and key-person risk, and the gap between the roadmap being promised and what the codebase can realistically support.

That last item is the one that changes deals. A roadmap that assumes six months of feature delivery on a system that needs six months of remediation first is a valuation problem, not an engineering opinion - and it is the finding buyers most often act on.

• Code quality, tests and maintainability
• Architecture, scalability and failure modes
• Security posture and dependency / licence risk
• Infrastructure cost trajectory under the growth plan
• Key-person risk and team structure
• Roadmap feasibility against the actual codebase

02Cost and timeline

Due diligence is priced by depth and estate size. A focused review of a single product is a very different exercise from assessing a group with several acquired systems, and honest providers scope it as a range until they have seen the repository list.

03The findings that most often change a decision

Key-person risk appears more often than any other material finding. A system where one person holds the operational knowledge is a risk that survives the transaction, and it is rarely visible from the outside because that person is usually the one giving the tour.

After that: dependency and licence exposure, particularly copyleft licences in a commercial product; security posture that would fail the acquirer's own compliance regime; and infrastructure cost that scales linearly with customers when the financial model assumed otherwise. None of these are unusual, and all of them are cheaper to know before signing.

04Commission it earlier than you think

Most technical due diligence happens too late, when a deal is largely agreed and the findings can only be used to renegotiate or walk away. Commissioned earlier, the same work shapes the deal - what to ask for, what to price in, what to make a condition.

The same applies to the internal version. If a board is uneasy about delivery, a two-week assessment now is worth more than a full diligence in six months, because there is still time to act on what it finds.

05Choosing who does it

The reviewer should be a practitioner. Assessing whether an architecture will hold under three times the load requires someone who has operated systems at that scale, not someone applying a checklist. Ask directly what the reviewer has built and operated.

Independence matters too. A firm that would like to win the remediation work has an incentive to find a lot of it. That does not disqualify them, but the assessment should be separately priced and the report should stand on its own - usable by your own team or any other vendor.

• Reviewers should be practitioners, not checklist auditors.
• Price the assessment independently of any remediation.
• The report should be usable by any vendor, not just the author.
• Ask for a risk register with severity and remediation cost.