Technical due diligence
What the code and the team are actually worth
An independent read on the technology behind a deal — before you buy it, invest in it, or bet a roadmap on it. Written for the people making the decision, not for engineers.
In short
Technical due diligence is an independent assessment of whether the technology behind a deal supports the valuation. It covers architecture and scalability, code quality and test coverage, security posture and data handling, third-party and licence exposure, infrastructure cost, key-person risk, and the size of the technical debt the buyer would inherit. The output is a risk register with each finding priced — remediation cost, timeline and whether it is a negotiating point or a walk-away.
When it applies
Signals this is the work
If more than one of these is true today, the problem is usually further along than it looks from the outside.
You are acquiring a company
The product demos well. Nobody outside the target has read the code or seen the infrastructure bill.
You are investing
The team says the platform scales. You need that checked by someone with no stake in the round closing.
You are being acquired
A buyer will run this on you. Knowing what they will find, first, is worth more than hoping they miss it.
You inherited a system
A merger, a departure or a restructure left you owning software nobody currently employed chose.
The roadmap keeps slipping
Estimates are consistently wrong in the same direction, which is usually a structural signal rather than a people one.
How we do it
The sequence
- 01
Understand the thesis first
What has to be true about the technology for the deal to work? That question shapes everything examined, and stops diligence becoming an undirected code review.
- 02
Architecture and scale
Whether the design supports the growth in the plan, and what breaks first if it arrives. Stated capacity is tested against how the system actually behaves.
- 03
Code and delivery health
Test coverage, build and release process, branch and review discipline, and how long a small change genuinely takes to reach production.
- 04
Security and data
Access control, secrets handling, dependency exposure, personal-data flows and what a breach would reach.
- 05
People and knowledge risk
How much of the system exists only in one person. This is the finding that most often changes a valuation.
- 06
Cost to own
Infrastructure, licences, and the engineering capacity needed to keep the thing standing before it does anything new.
- 07
Priced risk register
Every finding with a remediation estimate, so the output is usable in a negotiation rather than a list of concerns.
What we will not do
The refusals
- Produce a report that justifies a decision already taken.
- Score a codebase against a house style rather than against the deal thesis.
- Flag every finding as critical. If everything is red, nothing is.
- Assess a team we were not allowed to speak to, and present it as complete.
Questions
Before you ask
Related
Others in Strategize
Tell us what isn't working.
One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.