Most acquirers review the numbers line by line. The code that produces those numbers gets a fraction of that attention.
That is a risky imbalance.
In a software company, technology is not a support function. It is part of the product, part of the operating model and often part of the growth case. Yet Technical Due Diligence is still often treated as a box to tick: something that runs in parallel and gets condensed into a short summary.
That is how critical risks remain invisible until after closing.
The most expensive problem is often the one you did not price
McKinsey describes a communications hardware maker that acquired a network monitoring software company. The issue surfaced only after closing: a critical part of the code was not owned by the company. It was licensed. When the owner of that code was later acquired by a competitor, access disappeared. Rebuilding it cost tens of millions of dollars and delayed plans by 24 months.
No financial due diligence would have caught that risk on its own. It was not visible in the income statement. It sat in the code and in the licence agreements behind it.
The same McKinsey article describes a healthcare equipment maker that acquired an imaging company. The software worked on its own, but it was not compatible with the buyer’s existing systems.
Both examples follow the same pattern. The technology worked. It just did not work for what the buyer needed it to do.
What this means for you: the risks that cost the most are often not bugs. They are questions of ownership, dependency and fit. You only find them early if someone assesses the code, architecture and contractual conditions together.
A technical finding should change the deal
KPMG lists the questions a Tech DD needs to answer. Can the platform scale to support the investment thesis? What is the state of code quality and technical debt, meaning shortcuts that are likely to create future cost and delay? How dependent is the company on a small number of key developers? And who actually owns the intellectual property, including open source and third-party licences?
The important part is what happens next.
According to KPMG, technology findings should be translated into transaction consequences: purchase price adjustments, future investment requirements, terms in the transaction documents and priorities for integration.
Technical debt is not just a technical concern. It is a future cost and should be treated accordingly.
What this means for you: a buyer who knows that test automation is missing and that every release depends on two people has a concrete argument at the negotiating table. A buyer who does not know is more likely to pay for that risk afterwards.
The people are part of the technology
McKinsey reviewed 40 digital, analytics and technology acquisitions over two decades. One result stands out. When engineers left after the deal, it correlated closely with acquisition failure. When senior executives left, there was no such link.
That says something important about where the value sits. In technology businesses, critical knowledge often sits with the people who understand the systems in detail.
What this means for you: a good Tech DD does not only assess the systems. It also assesses how knowledge of those systems is distributed. Is there documentation? Are there tests? Is the architecture understandable and maintainable? Or does critical knowledge sit with three people who may not stay?
Uncertainty takes time, and time costs money
Researchers at the University of Manchester studied acquisitions of privately held technology firms in the UK (Javaid et al., 2023). They found that uncertainty about the target’s technology, measured through pending patent applications, makes due diligence take longer. The effect grows the further the target’s technology is from the buyer’s own. When the businesses are similar, it goes faster.
What this means for you: the less familiar the technology is to you, the more important independent technical judgement becomes. Otherwise the process risks becoming either slow or shallow.
This is also why Tech DD is moving earlier in the deal process. EY-Parthenon describes how it increasingly runs in earlier stages, integrated with commercial and operational due diligence, rather than bolted on at the end.
Due diligence is not a check. It is decision support.
A Tech DD that only confirms that the technology exists gives limited value. A useful Tech DD shows what the technology is likely to cost to own, improve, scale and integrate. That gives buyers a stronger basis for valuation, negotiation and post-deal planning.
At System Verification, we provide independent assessment of software, systems and technical risk. We translate technical findings into business consequences: what creates risk, what may require additional investment and what should be addressed first after closing. That helps buyers understand what they can trust before the transaction is complete.