Technical due diligence is not a code quality competition, and teams preparing for one usually spend their time on the wrong thing. Nobody buying a company is grading your abstractions. They are trying to work out what it will cost to own this system, and how badly it can go wrong after the money changes hands.

That reframing matters because it changes what you should fix first. Ugly code that works, is understood by the team and can be changed safely is a minor finding. Elegant code that only one person understands is a serious one, and it is the second that moves the price.

The question behind every question: if the founding engineer leaves the week after completion, does this system keep running and keep changing? Almost every finding that reduces an offer is a specific answer to that. Concentration of knowledge, undocumented deployment, licences nobody checked, credentials in one person’s head.

What Technical Due Diligence Is Really Assessing

Four risks, in roughly the order they affect valuation.

Key person risk. Whether the system depends on individuals rather than on documented process. This is consistently the most damaging finding because it is the hardest to fix after the fact and it directly threatens the thing being bought.

Cost to continue. What it takes to keep the system running and evolving: infrastructure spend, licence obligations, the size of team required, and how much of the roadmap will be eaten by maintenance rather than new work.

Liability. Licensing that conflicts with commercial use, personal data handled in ways that would not survive a complaint, security exposure, and any regulatory obligation the company is not actually meeting.

Ability to change. Whether new features can be delivered at a predictable rate, or whether every change carries a risk of breaking something unrelated.

Code quality matters only through the fourth of these, which is why a reviewer will spend less time reading your code than founders expect and more time asking how deployments happen.

The Findings That Reduce the Price

Nobody can deploy but one person. A release process that lives in somebody’s head, or on their laptop, is treated as a serious operational risk regardless of how well it works today.

No test coverage on the paths that matter. Not a coverage percentage, which reviewers largely ignore, but whether the system can be changed with any confidence at all. A codebase with no tests around the revenue path prices in a slower roadmap. Our guide to software testing strategies covers what actually earns its place.

Licence contamination. Copyleft code inside a proprietary product is one of the few findings that can stop a transaction rather than merely repricing it, and it is usually discovered by a scanner in minutes.

Personal data with no defensible basis. Data collected without a clear lawful basis, retained indefinitely, or held somewhere the company cannot enumerate. The GDPR technical compliance mechanics are the same ones a reviewer checks.

Undocumented dependencies on individuals or vendors. A critical integration with a supplier under no contract, or infrastructure in a personal account, both read as unmanaged risk.

Security basics missing. Not a penetration test result, but whether secrets are in version control, whether access is revoked when people leave, and whether anything is currently unpatched and internet-facing.

What Reviewers Do Not Care About

This is worth stating because preparation time is limited and usually misspent.

They do not care which framework you chose, provided people can be hired for it. They do not care about architectural fashion; a monolith that ships is not a finding. They do not care about code style, naming, or the absence of a pattern somebody on the internet recommends.

They also do not expect zero technical debt. Every company has it, and its presence is normal. What matters is whether the team knows where it is and can describe what it costs. A team that produces a clear list of its own known problems reads as competent. A team that claims there are none reads as unaware, and the reviewer then has to find them unaided, which takes longer and produces a worse write-up.

Preparing Without Rewriting Anything

Most of what helps takes days, not months, and none of it involves touching the architecture.

Write down how to deploy it. From an empty machine to a running system. This single document addresses the most damaging category of finding and can be written in an afternoon.

Enumerate your dependencies and their licences. Automated tooling produces this quickly, and knowing the answer before a reviewer does is worth considerably more than a clean result.

Get secrets out of version control and inventory who has access to what. Then remove access for anyone who has left.

Document what you know is wrong. A short, honest register of known issues with rough remediation cost. Volunteering this is one of the few things that reliably improves how a review reads.

Make sure infrastructure is owned by the company, not by an individual account, and that domains, certificates and repositories are all under corporate control.

What Happens to the Findings

They rarely kill a deal. They become conditions.

Findings typically resolve into one of three outcomes: a price adjustment reflecting remediation cost, a warranty or indemnity in the agreement, or a condition to be met before completion. Only licence contamination and serious unaddressed data protection exposure regularly stop transactions outright.

Which means the practical goal is not a perfect system. It is a system whose problems are known, bounded and describable, because a quantified problem gets priced while an unquantified one gets assumed to be worse than it is.

Mecanik runs technical reviews of this kind as part of our software development work, usually from the buyer’s side. The pattern is stable: the systems that review well are not the sophisticated ones, they are the ones where somebody wrote things down.

Related reading: Software Escrow: Who Actually Needs It , Fintech Software Development UK: FCA, Rails and Cost , Fixed Price Contract or Time and Materials? and Custom Software Development UK - The Complete Buyer’s Guide .

Frequently Asked Questions

What is technical due diligence? An assessment of what it will cost to own a software system and how badly it can go wrong after an acquisition or investment. It examines key person risk, cost to continue, legal liability and the ability to keep changing the system, rather than grading code quality for its own sake.

What findings reduce the price most? Concentration of knowledge in individuals, particularly a deployment process only one person can perform. After that: no meaningful test coverage on revenue paths, licence contamination from copyleft code in a proprietary product, personal data with no defensible lawful basis, and secrets committed to version control.

Do reviewers care about my technical debt? They expect it. Every company has some and its presence is not a finding. What matters is whether the team knows where it is and can describe what it costs to fix. A clear register of known issues reads as competence; claiming there are none reads as unawareness and makes the review worse.

How do I prepare for technical due diligence? Write down how to deploy the system from an empty machine, enumerate dependencies and their licences, remove secrets from version control, review who still has access, confirm infrastructure and domains are owned by the company rather than individuals, and produce an honest register of known problems with rough remediation costs.

Can a technical finding stop a deal completely? Rarely. Most findings become price adjustments, warranties in the agreement, or conditions to satisfy before completion. The exceptions that do stop transactions are copyleft licence contamination inside a proprietary product and serious unaddressed data protection exposure.