Technical due diligence: what it is and what gets examined

Technical due diligence is the review a buyer or investor commissions before committing to a deal. That deal is usually an acquisition, a funding round, or a major partnership. An outside reviewer examines the code, the architecture, the security posture, and the team behind the product, then delivers a verdict on what the technology is actually worth and what problems come attached to it. That verdict becomes a risk picture the deal team uses to negotiate price, terms, or whether to proceed at all.

This page covers what gets examined and what the findings mean once a deal is on the table. For the week-by-week mechanics of running one, see how a technical due diligence runs.

Who commissions it and why

The buyer varies, but the request usually comes from one of three places: a venture or growth investor checking whether the product can actually support what the company is promising, an acquirer figuring out whether they're inheriting a system worth building on or one that needs a rewrite, or a board sizing up a partnership that would put a chunk of the roadmap in someone else's hands.

What the review feeds into is usually blunt: close at the agreed price, close at a different one, or walk away. A growth investor evaluating a healthtech target, for example, cares less about code style than about whether patient data is handled the way regulators expect. A strategic acquirer buying a smaller competitor cares more about whether the two codebases can merge through ordinary system integration or need a rewrite first.

The five areas technical due diligence examines

A reviewer covers five areas, spending the most scrutiny wherever the deal's risk actually sits.

• Code quality and ownership. A real test suite exists and actually runs, and a second engineer reviews every change before it ships. Ownership matters too: the company actually owns the code it's selling, rather than licensing pieces of it from contractors who never signed anything over.
• Architecture and scalability. Whether the system is cut into sensible pieces, whether data is centralized or scattered, and whether it holds up if usage triples, or whether the reviewer is really looking at a legacy modernization project waiting to happen.
• Security and compliance. Authentication, data handling, dependency hygiene, and whichever regulatory regime the product falls under.
• Team and bus factor. Who actually understands each part of the system, and what happens to that knowledge if two or three people leave in the same quarter.
• IP and licensing. Every dependency's license needs to be compatible with a commercial product, and the code itself needs to be legally owned, free and clear.

That scrutiny shifts with the deal: a payments acquisition leans harder on security and compliance, a platform merger leans harder on architecture.

What counts as a red flag

Some findings matter more than others, and the same ones tend to turn up deal after deal.

• No tests on the payment path. Missing coverage somewhere in the codebase is normal; missing it on the code that moves money is a different, more common risk than buyers expect.
• Just one engineer who can explain how the core works. Ask what happens if that person takes a two-week vacation, and if the honest answer involves the word "hope," that's usually the sharpest item on the list.
• GPL or another copyleft license inside a proprietary product. Easy to miss during development, expensive to discover later, since it can force the surrounding code to be released under the same terms.
• Customer data flows nobody documented. Years of features added by different people, with nobody writing down where personal data ends up or how long it's kept, until someone asks and there's no answer ready.

Most real codebases carry at least one of these somewhere. What varies deal to deal is how many show up together, and how deep they go.

How findings change a deal

Findings rarely kill a deal outright. More often they move it. When the code doesn't back up what the team has been claiming, that shortfall becomes a number: a lower purchase price, a portion of the payment held in escrow until a specific issue is fixed, or a remediation commitment with a deadline attached. Sometimes the fix is priced in before close; sometimes it becomes the buyer's problem afterward, at an already-discounted price.

Walking away is rarer than people assume, reserved for findings that are structural rather than fixable: code the company doesn't actually own, a security posture that can't be fixed inside the deal timeline. Most reviews end in a number, not a no.

When to bring in an outside reviewer

An outside reviewer is worth the cost in two situations. The first is independence: an investor or acquirer needs an opinion nobody involved in the deal can dismiss as biased, which rules out anyone already on either side's payroll. The second is unfamiliar territory: a board evaluating a target built on a stack nobody in-house has run in production, where judging the architecture means having operated something similar under load.

Neither situation calls for someone already close to the deal. Both call for someone who has faced decisions like these before, with nothing riding on how this particular deal turns out, free to say plainly what they find. That's the software development consulting work we do for investors and acquirers ahead of a deal, sometimes alongside a fractional CTO engagement when the buyer needs technical judgment in-house through the transition.