Technical due diligence gets treated by engineering teams as an exam on code quality, which produces defensive answers about legacy modules and refactoring plans. That is not what is being assessed. The buyer is estimating risk and future cost: what breaks, what it costs to run, who understands it, and what has to be fixed before the product can grow.
01The four questions underneath every other question
Can this keep running if key people leave? Can it scale to the growth in the plan without a rewrite? Is there a liability hidden in it - licensing, security, personal data? And how much will it cost to maintain relative to what the model assumes?
Every detailed question maps back to one of these. Understanding that changes how you prepare, because the goal is not to demonstrate excellent engineering. It is to demonstrate that the risks are known, bounded and being managed deliberately.
| Area | What they check | Signal |
|---|---|---|
| Key-person risk | Bus factor per critical system | Can they operate it post-close? |
| Deployment | Frequency, rollback, automation | Can the team ship reliably? |
| Testing | Coverage on critical paths, CI | Will changes break things? |
| Security | Known issues, dependency age, secrets | Is there a breach waiting? |
| Licensing | Copyleft in a commercial product | Is there a legal problem? |
| Infrastructure cost | Cost per customer, trajectory | Do the unit economics hold? |
02Key-person risk is examined harder than code quality
A codebase with rough edges that five engineers understand is a far better proposition than an elegant one only its author can change. Diligence teams probe this directly: who is the only person who understands the billing logic, and what happens if they leave three months after close?
Prepare by being honest about it. A documented list of concentration risks with a mitigation plan reads as competent management. Claiming everything is well distributed, and then having the diligence team discover one person's name on ninety percent of commits to a critical service, reads as either unawareness or evasion.
03Licensing is the one that kills deals
Most technical findings are negotiated. Copyleft licensing in a commercial product is different, because it can create an obligation to release source code, and a buyer's lawyers will not accept ambiguity about it.
Run a licence scan across your entire dependency tree before diligence starts, including transitive dependencies. Finding a GPL library deep in a dependency chain during the buyer's scan is a materially worse position than finding it yourself six months earlier and replacing it quietly.
| Finding | Severity | Typical consequence |
|---|---|---|
| Copyleft licence in the product | Deal risk | Remediation required before close |
| Unresolved breach or exposed data | Deal risk | Indemnity, escrow, possible walk-away |
| Single point of knowledge on core system | High | Retention package, price adjustment |
| No tests on critical paths | Moderate | Factored into integration cost |
| Ageing dependencies | Moderate | Remediation plan requested |
| Ugly but working legacy code | Low | Noted, rarely priced |
04Show that you know your own weaknesses
The most effective preparation is a written technical assessment of your own systems, including the parts you are not happy with, with a plan and rough costs. This changes the dynamic completely: instead of the buyer discovering problems, they are reviewing your analysis of problems you already identified.
It also makes you a better negotiator. When a finding appears in their report that was already in your document, it is a known quantity rather than a surprise, and known quantities are much harder to use as a reason to reprice.
05Practical preparation, three months out
Get architecture documentation into a reviewable state. Run licence and security scans and remediate anything serious. Reduce bus factor on the two or three most critical systems by pairing someone else into them. Make sure the deployment process is documented and demonstrably works.
Then assemble the data room: architecture, infrastructure costs, incident history, security posture, dependency inventory, and the team's areas of ownership. Diligence teams that receive organised material move faster and find less to worry about, and speed is worth real money in a transaction.
Topics
Marcus Hale
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer