What a Technical Due Diligence Actually Finds

When you buy a software business, you buy its codebase. Not the demo, not the roadmap, not the architecture diagram somebody drew for the data room. The code itself, with whatever is in it.

The financial due diligence tells you what the business earned. The technical one tells you what it will cost to keep earning it.

Those are different questions, and the second one is where deals go wrong quietly.

What the review is looking for

To ensure clarity from the start, its not bugs, because bugs are cheap and every codebase has them. It is:-

Can this system be changed? A codebase nobody can safely modify is a business that cannot ship features, respond to a competitor, or meet a compliance deadline. That is the finding that most often moves a price, and it never appears in a financial model. We have written about what an unchangeable codebase costs and how to spot one from the owner’s side of the table.

Who understands it? If one engineer holds the whole system in their head and they are not part of the deal, you are buying a liability with a resignation date. This is worth asking about directly, and worth checking against the commit history rather than the org chart.

What is it built on? Every system carries dependencies, and some of those are abandoned, unlicensed for commercial use, or carrying known vulnerabilities. The question is not whether vulnerabilities exist. It is which ones are reachable from code that runs in production, because those are the ones that matter and they are usually a small fraction of what a scanner reports.

What happens under load it has not seen? A system serving two hundred customers is not necessarily a system that serves two thousand. The architecture tells you whether growth is a configuration change or a rewrite.

The one with the time bombs

The engagement worth telling here came out of a dispute rather than a friendly sale. A project manager had walked away with a platform an investor had paid to build, locked the investor out, and claimed the code as their own. We were brought in twice. First, before anyone had access, to tell the solicitor what to demand: which repositories, which hosting accounts, which databases, because a legal team cannot request what it does not know exists, and an incomplete request list is how assets quietly stay behind. Then again at the final stage, when access was granted, to review what came back.

The brief was modest: confirm there was enough code to keep operating. What the review found was not a quality problem. It was sabotage. Code scheduled to delete itself, including a job that phoned a hidden repository at four in the morning and removed itself from the stack if the connection failed. Debug routes left open into the production databases of the platform’s largest customers. Access holes opened in the days before handover. Repositories that existed nowhere in the material being handed across.

The buyer did not walk. They renegotiated, with each finding as a bargaining point and as documented evidence of bad faith, while we defused what had been planted and locked the stack down. That is the general shape of a finding that changes a deal: it rarely kills the purchase, it reprices it and tells the lawyers exactly what to write into the warranties. The same shape has held from association platforms worth millions to tens of millions, across legal societies and pharmacy, logistics and critical infrastructure. The findings rhyme at every size.

Why the automated scan is not enough

A standard security scanner would have passed the codebase above. That is worth sitting with. A system rigged to delete itself, with open routes into its largest customers’ databases, and a scan report would have come back with the usual list of housekeeping.

That is because a scanner reads code the way you would read it on GitHub: at rest, in isolation. A four-in-the-morning job that deletes itself when a hidden repository stops answering is invisible at rest. It only exists as behaviour, on a specific host, connected to specific services, which is why our process examines a system in every state it lives in: at rest, on a developer’s machine, on staging, and running in production. That is how the time bombs were found, and it is the difference between reviewing the code and reviewing the system.

The same blind spot works in reverse. A well-known detection vendor reviewed a compromised environment and concluded the malicious code had sat there for months, putting the breach outside everyone’s warranties. The attacker had simply altered the visible file dates, an old anti-forensic trick called timestomping. The filesystem’s master file table keeps a second set of timestamps most tools never read, and comparing the two took seconds: the intrusion was recent, the story was planted, and the real timeline changed who was accountable. The vendor’s tool trusted a surface that can lie, and it read the lie fluently.

The quieter version of the same problem shows up on ordinary deals with no sabotage in them at all. Run a standard scanner over an unfamiliar codebase and you get hundreds of findings, most of them noise. The work is not producing that list, it is tracing which items on it are reachable from code that runs in production, which is why we built CodeScan to do reachability analysis rather than presence detection. A vulnerable function that nothing ever calls is a housekeeping item. The same function on the login path is a different conversation entirely, and a raw scan report treats them identically.

Then there are the findings no ruleset will ever hold, because they are architectural: a data model that cannot support the roadmap, an integration with no reconciliation, a single point of failure that everybody has stopped noticing. Those come from reading the system the way the story above was read, asking what it does rather than what it contains.

What it cannot tell you

Worth being clear about the limits, because a review that oversells itself is worse than none.

It cannot tell you whether the team will stay. It can tell you how concentrated the knowledge is, which is a proxy, but people decide for their own reasons.

It cannot value the business. It can tell you what remediation would cost and how long it would take, and that is an input to your model rather than a substitute for it.

It cannot find everything in a fixed window. A review is a sampling exercise guided by risk, not a proof of absence. Any provider who tells you they have found everything has told you something useful about the provider.

When it is too late

The findings that change a price only change it before the price is agreed.

Running the review after signing is still worth doing, because you need to know what you now own and what the first six months of engineering work will be. But you have swapped a negotiating position for a to-do list. The moment that serves you is when you have exclusivity and repository access, with enough time left that a serious finding can still be acted on.

The week before settlement is when most people call, and by then the review can only confirm what you have already committed to.

What you should get at the end

A plain-language account of what you are buying, not a tool output.

That means the caller map and risk surface, which is the honest answer to whether the system can be changed. The remediation estimate in time and money. The concentration analysis of who knows what, and whether growth is a configuration change or a rewrite. And a clear separation between what is genuinely fragile and what is merely untidy, because untidy code is normal and fragile code is a number in your model.

That number is the one the financials cannot give you. They told you what the business earned. This is what it will cost to keep earning it. You are buying the codebase, with whatever is in it, and the review’s job is to tell you what is in it while the price can still move.

We run technical due diligence for acquirers across Australia, usually two to six weeks and scoped to the deal rather than the codebase size. If you are looking at a software acquisition, the useful time to talk is before you sign anything. Get in touch or call 1300 840 340.