Technical due diligence

Technical due diligence is the part of a transaction where a buyer works out whether the software they are about to pay for is worth what they think it is worth. It runs alongside financial and legal diligence, and it answers a narrower question than people expect: not "is this good code" but "what will it cost, in money and time, to keep this product running and growing after the deal closes?"

That framing matters, because it explains why buyers care about things engineers sometimes consider trivia. Nobody is grading style. They are pricing risk.

What it actually covers

Scope varies by deal size, but nearly every process touches the same six areas. Our technical due diligence checklist breaks each of these down into the specific questions asked.

1. Architecture and technology choices. Is the system built on something that will still be supportable in five years, and can it handle the growth in the buyer's model?
2. Code quality and technical debt. Not aesthetics. Whether new engineers can be productive quickly, and what the known shortcuts will cost to unwind.
3. Delivery process. How changes reach production, how often, and how much manual effort and risk each release carries. See the DevOps maturity model for the framework most reviewers use here.
4. Security and compliance. Access control, data handling, vulnerability management, and whether the company can survive its customers' security questionnaires.
5. Infrastructure and scalability. Hosting, cost per unit of usage, disaster recovery, and what breaks at 10x load.
6. Team and key-person risk. Who actually knows how the system works, and what happens if they leave. This is consistently the single most damaging finding.

How the process runs

Most engagements follow the same shape, whether they take one week or four:

1. Questionnaire. A written request sent to the target covering all six areas. This is the bulk of the work for the company being assessed. See the due diligence questionnaire guide for how these are structured.
2. Document review. Architecture diagrams, incident history, security policies, dependency and license inventories.
3. Interviews. Usually the CTO or engineering lead, plus one or two senior engineers. Reviewers often learn more from the difference between those two accounts than from either alone.
4. Code and environment access. Sometimes read-only repository access, sometimes only automated scan output. Many targets resist this, and a good reviewer can work without it.
5. Findings report. Risks, severity, and what remediation would cost. This is the artifact that affects price.

What buyers are really looking for

Reviewers are not hunting for perfection. Every codebase has problems, and a report with no findings would be treated as evidence the reviewer did not look hard enough. What changes a deal is a specific short list:

• Concentration of knowledge. One person who is the only one who understands a critical system. This is a valuation issue because it is a retention issue.
• Undisclosed licensing exposure. Copyleft-licensed open source inside a proprietary product, or unlicensed commercial dependencies.
• Security posture that will not survive the buyer's customers. If the acquirer sells into enterprise and the target cannot pass a standard security review, that is a revenue problem, not an engineering one.
• A delivery process that cannot absorb a roadmap. If shipping takes weeks and requires heroics, the acquirer's plans for the product are fiction.
• Cost curves that break the model. Infrastructure spend that scales linearly with users when the model assumes it does not.

If you are the company being assessed

The single most useful thing to understand is that surprises are what damage you, not problems. A known, documented, costed weakness is something you negotiate around. The same weakness discovered by the buyer's reviewer becomes leverage against your price and a reason to question everything else you said.

Almost every finding that lands badly was already known to the engineering team. It simply had never been written down or escalated. Running the assessment on yourself first, well before a process starts, converts discoveries into disclosures.

If you are the one doing the assessing

The hard part is not knowing what to ask, it is getting honest answers efficiently. Two things help more than anything else:

• Ask the team, not just the leader. The gap between what a CTO believes about the delivery process and what the engineers report is often the most informative signal available, and it is invisible if you only interview one person.
• Score against a fixed framework. Free-form review produces findings that are hard to compare across deals. A consistent maturity model lets you say "this target is weaker than the last three on delivery" rather than just "this felt shaky."