Technical Due Diligence: What to Actually Check Before Acquiring a Software Company

Financial due diligence gets careful attention in most acquisitions because the numbers are the deal. Technical due diligence gets a lighter pass, often a single afternoon of a contracted developer skimming a repository, which is a mistake — the codebase and the team behind it are what you're actually going to own and operate after the deal closes, long after the founders who built it have vested out and moved on.

Codebase health, not codebase style

Reviewers new to this often focus on code style — naming conventions, formatting — which matters far less than structural health: test coverage on critical paths, how tightly coupled major components are, whether the architecture can scale past current load, and how much of the system depends on deprecated libraries or unsupported services. A messy but well-tested, modular codebase is a manageable inheritance. A pretty but untested, tightly coupled one is a slow-motion liability that shows up as ballooning maintenance cost within the first year of ownership.

• Test coverage on revenue-critical paths, not overall percentage alone
• Dependency audit — outdated, unmaintained, or unlicensed packages
• Architecture review — can it scale 5-10x without a rewrite
• Security review — authentication, data encryption, past incident history
• Deployment process — can the new owner actually ship a change safely on day one

The bus factor problem

A frequently underweighted risk: how many people actually understand the system deeply enough to change it safely. If critical knowledge lives in one or two engineers' heads and isn't documented anywhere, that's not a personnel detail — it's a material risk to the asset you're buying, because those engineers may not stay past their retention bonus, and untangling undocumented decisions after they leave is expensive and slow.

Technical debt has a real dollar figure

Every acquirer should leave due diligence with an actual estimate — not a vague impression — of what it will cost to bring the codebase to a maintainable state: security patches that were deferred, a database migration that's overdue, a monolith that needs decomposing before it can scale to the acquirer's user base. That number belongs in the valuation conversation, not discovered six months after close when it's your engineering team's problem instead of a negotiating point.

Data and infrastructure ownership

Confirm, explicitly, who actually controls the domains, cloud accounts, SSL certificates, and third-party service contracts — it's more common than it should be for critical infrastructure to be registered under a founder's personal account rather than the company's, which becomes a real problem the moment that founder is no longer involved and unreachable.

The short version

A demo shows you the happy path. Technical due diligence needs to check test coverage, architecture scalability, the bus factor on institutional knowledge, and a real dollar estimate of deferred technical debt — then get that number into the valuation, not treat it as a post-close surprise. The few thousand dollars a proper technical audit costs is cheap insurance against inheriting a codebase nobody can safely touch.

Sources