Technical due diligence: what acquirers and investors actually check

01What is actually examined

Diligence typically runs two to six weeks and covers more than code. The reviewers are looking for risks to the value of the asset - things that would require unexpected investment, create legal exposure, or mean the product cannot scale the way the business plan assumes.

02Open source licensing gets checked properly

Automated scanning of dependency trees is standard, and it looks at transitive dependencies rather than only direct ones. The concern is copyleft licences - GPL and AGPL in particular - appearing in a proprietary product where the licence obligations conflict with the commercial model.

AGPL in a hosted SaaS product is the specific case that causes trouble, because the network-use provision can trigger source disclosure obligations that a proprietary vendor cannot meet. Scan your own tree before diligence rather than learning about it in a findings report.

• Run a licence scan across transitive dependencies, not just direct.
• Flag GPL, AGPL and other copyleft in anything shipped or hosted.
• Keep an SBOM current - increasingly expected rather than impressive.
• Document any licence exception or commercial licence you rely on.

03Key-person risk is assessed bluntly

Reviewers will ask which systems only one person understands, and they will get an honest answer from your engineers even if the leadership answer is more polished. A codebase where one individual is the sole route to understanding a critical service is a valuation risk, because that person may not stay through the transition.

The fix is unglamorous and effective: documentation of the non-obvious parts, shared ownership of critical services, and a demonstrable ability for someone else to deploy and debug them. This takes months, which is why it needs starting long before a process begins.

• Identify single points of knowledge honestly, then reduce them.
• Architecture decision records explaining why, not just what.
• Runbooks for the things that page someone.
• At least two people able to operate every critical system.

04What reviewers read as positive signal

Diligence teams form a view quickly about whether an engineering organisation is disciplined. A handful of observable signals do most of that work, and they are all things a well-run team already has.

• A README that lets a new engineer run the system locally.
• CI that runs tests on every change, with visible history.
• Meaningful test coverage on the parts that carry risk.
• Infrastructure as code rather than manually configured environments.
• A dependency upgrade cadence rather than years-old versions.
• Incident history with written post-mortems - having incidents is normal, not learning from them is not.

05Preparing, ideally a year out

The work that improves a diligence outcome is the work that improves the engineering organisation anyway, which makes it easy to justify independently of any transaction. What it cannot be is compressed - a codebase cannot be made maintainable in the six weeks before a review.

Run your own diligence first. Commission an external technical review, receive the findings while you still have time to act, and fix what matters. Arriving at a real process with known and mitigated issues is a substantially stronger position than being told about them by the buyer's advisers.

• Resolve IP assignment for every contractor and founder, in writing.
• Scan and remediate licensing before anyone else does.
• Reduce key-person concentration on critical systems.
• Document architecture and the decisions behind it.
• Address known security findings, and keep evidence you did.
• Commission an independent review a year ahead of any process.