Software Due Diligence: What Acquirers Miss When They Only Audit the Balance Sheet

A deal team walks into a data room. The financials are stress-tested. The legal review is clean. The commercial DD confirms the market position. The management presentation was polished, credible and delivered with exactly the right amount of confidence.

The deal closes on schedule. The integration plan kicks off on Monday.

Six months later, the fund discovers that the platform can’t scale to support the growth thesis without a rebuild that will cost two years and several million in engineering investment. The core product feature described as proprietary in every investor presentation is actually a configuration layer sitting on top of a vendor system that can renegotiate its terms the moment ownership changes. And the one engineer who can deploy the product to production has been interviewing elsewhere since before the deal closed.

None of this was in the data room. All of it was in the codebase.

This scenario is not hypothetical. It’s the pattern that repeats across technology acquisitions wherever software due diligence gets skipped or reduced to a surface-level review that checks boxes without understanding what’s underneath them.

The Blind Spot in Traditional Due Diligence

Traditional due diligence is thorough on the things it’s designed to assess. Financial DD tells you whether the numbers are reliable. Legal DD tells you whether the contracts are enforceable. Commercial DD tells you whether the market position is defensible.

None of them tell you whether the technology can do what the investment thesis requires it to do.

This isn’t a criticism of those disciplines. It’s a description of their scope. Financial DD can tell you that the company spends three million a year on engineering. It cannot tell you whether that spend produced a scalable platform or a fragile monolith held together by one person’s institutional memory. Legal DD can review the employment agreements. It cannot tell you whether the IP assignment clauses in those agreements actually cover the code that the founders wrote before the company was incorporated.

The information memorandum describes what management believes the technology is. The balance sheet records what the company spent building it. Neither of those is the same thing as what the technology actually is.

That gap, between what’s described and what exists, is where acquirers lose money. Not because anyone deliberately misrepresented the technology, though that happens occasionally. More commonly, because the people describing it genuinely believe it’s better than it is. They use terms like “cloud-native” and “proprietary” and “AI-powered” because those terms describe what the technology was supposed to be, or what it was when they last looked closely, or what the marketing team started calling it three years ago.

The only way to close that gap is to have someone who understands technology actually look at it. Before the money moves.

What Software Due Diligence Actually Examines?

Software DD isn’t a code review. It’s a structured assessment of whether the technology, the code, the architecture, the infrastructure, the data, the team, the vendor relationships and the intellectual property, supports the investment thesis or undermines it.

The assessment covers several domains, but five of them consistently produce findings that change deal outcomes.

Architecture reality versus architecture claims:

The IM says “cloud-native microservices platform.” The codebase reveals a monolithic application deployed on virtual machines in a cloud environment. Both descriptions are technically defensible. One can scale horizontally to support ten times current load. The other requires a fundamental rebuild before it can handle meaningful growth.

The architectural assessment maps what actually exists, how components are structured, how they communicate, where state is managed, how the system handles failure  and evaluates whether that architecture can support the growth plan the fund has modeled. If it can’t, the assessment quantifies the remediation cost. Fourteen to eighteen months of rebuild work at serious engineering cost is a common finding for platforms that accumulated years of architectural shortcuts under resource pressure.

That cost changes the deal economics. It belongs in the financial model. Without software DD, it belongs nowhere, until it surfaces post-close as an unplanned capital requirement.

Intellectual property chain of custody:

This is the finding that can kill a deal entirely, regardless of how strong everything else looks.

In healthy companies, IP ownership is clean. The company owns the code. Assignment clauses are standard. Registrations name the corporate entity. Nobody has a reason to question it.

In companies that grew fast, pivoted multiple times, or experienced founding team departures, the IP chain gets complicated. The first version of the product was built before incorporation. Early contractors worked on handshake agreements. The CTO who built the core platform left after a dispute and the separation agreement didn’t explicitly address IP assignment. Patents were registered to individuals because that’s who filed them.

Each of these situations is common. Each of them is fixable, usually. But fixing them during a transaction, when the other party knows you need the resolution to close, creates leverage dynamics that can delay the deal by months and add significant cost to what should have been a paperwork exercise.

Vendor dependencies with acquisition triggers:

A product’s core capability is often more dependent on third-party vendors than the IM suggests. The “proprietary credit decisioning system” turns out to be a configuration layer on a vendor platform. The “AI-powered analytics engine” relies on a third-party API that the company licenses rather than owns.

Dependencies aren’t inherently problematic. What makes them problematic in an acquisition context are the contract provisions that activate when ownership changes. Change-of-control clauses that trigger renegotiation rights. Data ownership provisions where the vendor, not the company, owns the historical records. Termination provisions that allow the vendor to exit the relationship within ninety days of a control event.

A vendor dependency that’s stable under current ownership can become a multi-million-dollar exposure the moment the acquisition closes. The vendor knows the acquirer needs the service. The renegotiation happens from a position of asymmetric leverage. The cost of switching vendors, if switching is even possible without significant rebuilding, adds to the total.

These findings don’t come from the codebase. They come from reading the vendor contracts. And nobody reads the vendor contracts unless the technical assessment identifies the dependency first and tells the legal team which contracts to pull.

Operational fragility and key-person risk:

How many people can deploy the product to production? How many people understand the core business logic deeply enough to modify it safely? How many people can diagnose and fix a critical production issue?

In well-run engineering organizations, the answer is “multiple people, supported by documentation, CI/CD pipelines and automated processes.” In companies that grew under pressure or went through rounds of cost-cutting, the answer is sometimes one person. Occasionally zero, the person already left and nobody has successfully deployed since.

A product serving thousands of customers where one engineer holds the deployment process, the production credentials and the undocumented knowledge of how the system actually works is a product that’s one resignation away from an operational crisis. In distressed acquisitions where morale is already low and retention is fragile, that’s not a theoretical risk. It’s a probable scenario on a specific timeline.

See also: How to Fly Business Class to Europe: Tips for Comfort and Savings

Technical debt as hidden liability:

Every codebase has technical debt. That’s normal. What matters for deal purposes is the distribution of that debt, where it is concentrated and what the consequences are.

Test coverage is the most reliable proxy. A company might report healthy aggregate test coverage while the modules that handle payments, authentication and regulatory compliance are effectively untested. The code that handles money, identity and data integrity, the code where a bug has financial or legal consequences, is often the least tested code in the system. Because it’s complex, because it has external dependencies and because under pressure teams test what’s easy and skip what’s hard.

When critical modules lack test coverage, modifying that code safely becomes nearly impossible. Every change risks introducing bugs that nobody will notice until a customer reports them. The remediation, writing tests, refactoring for testability, fixing the bugs that testing reveals, is a defined cost that belongs in the deal model.

Why the IM Can’t Tell You This

The information memorandum is a sales document. That’s not a criticism. It’s a description of its function.

IMs are written by people who describe what management believes the technology is, through the lens of what makes the asset attractive. When the IM says “scalable cloud platform with proprietary AI capabilities,” it’s describing an aspiration that might have been true at one point, or might be partially true, or might be what the technology was designed to be before the team was cut in half and the roadmap was abandoned.

The IM can’t tell you what the architecture actually looks like because the people who wrote it aren’t architects. It can’t tell you whether the IP chain is clean because nobody checked. It can’t tell you about the vendor contract provisions because the vendor agreements weren’t part of the management presentation.

This isn’t dishonesty. It’s the structural limitation of a document designed to sell an opportunity, not to assess a technology.

What the Findings Do to the Deal

The purpose of software DD isn’t to find problems. It’s to quantify problems in terms the deal team can act on.

A finding that the platform needs an eighteen-month rebuild before it can support the growth thesis doesn’t kill the deal. It reprice the deal by the cost of the rebuild. A finding that a vendor contract has a change-of-control clause doesn’t kill the deal. It adds vendor contract novation as a pre-condition of close. A finding that IP assignment documentation has a gap doesn’t kill the deal. It structures an indemnity or escrow arrangement that protects the acquirer.

The deals where findings kill the transaction are rare. The deals where findings change the price, the structure, or the integration plan are common. And the deals where findings would have changed everything but nobody found them, those are the deals that produce write-offs.

The Timing Objection

The most common reason acquirers skip software DD is timing. Deals move fast. Adding another workstream to a compressed timeline feels like a risk to the close.

A focused software assessment takes two weeks. For that investment of time, the deal team gets a clear picture of remediation costs, structural risks and dependencies that affect the thesis. The alternative is discovering those same things post-close, when the cost of remediation is real, the leverage dynamics have shifted and the option to reprice or restructure the deal no longer exists.

Two weeks of assessment versus months of unplanned remediation. The math is not complicated.

The Broader Pattern

The pattern across technology acquisitions is consistent. Companies that end up in acquisition conversations, whether growing fast, going through distress, or being consolidated by a platform buyer, were built under pressure. Speed was prioritized over architecture. Vendor relationships were established when the company had no leverage. Engineering decisions were made to survive the quarter. Documentation was deferred because it was never urgent.

None of this is unusual or blameworthy. It’s the natural consequence of building a company under real-world constraints. The technology still works. The business still serves customers. Under the right ownership with realistic expectations about the investment required, it can be genuinely valuable.

The problem isn’t the technology. The problem is pricing the technology based on a description rather than an assessment. The gap between those two, between what the IM says and what the codebase shows, is where acquirers lose money that they never needed to lose.

Software due diligence closes that gap. Not with an opinion about whether the technology is good or bad. With a specific, quantified picture of what the technology actually is, what it costs to bring it to where the thesis needs it to be and how to structure the deal to reflect reality rather than description.

That’s the job. And it takes two weeks.