$904 billion of buyout deals closed in 2025, up 44% on the year across 3,018 transactions. Almost every one of them came with a technical diligence report attached.
Those reports run two to four weeks and cover five things: architecture and scalability, the team, security and compliance, infrastructure spend, and roadmap risk. I have been on both sides of them. The operator being audited, and the person an investor calls three months after close when the plan is already behind.
Not one standard scope measures how long it takes the company to turn a decision into a shipped, safe change.
That number is the deal.
The thesis
Technical diligence audits the artefact. The value leaks out of the system.
You are not buying a codebase. You are buying a rate: the rate at which this business converts capital into shipped change without breaking the part that makes money. Nobody measures that rate before the wire clears. Then the value creation plan assumes a rate nobody has ever observed.
The arithmetic changed and the diligence did not
For roughly a decade, a buyout needed about 5% annual EBITDA growth to reach a 2.5x multiple on invested capital. Multiple expansion and cheap debt carried the rest. Bain’s 2026 report puts the requirement now at 10% to 12% annual EBITDA growth for the same outcome, with borrowing costs sitting at 8% to 9% and leverage at 30% to 40% of the capital structure.
Double the operating growth, from the same assets, under more expensive debt.
The rest of the picture makes it worse. There are 32,000 unsold portfolio companies carrying $3.8 trillion of value. Average holding periods at exit have stretched to around 7 years, up from the 5 to 6 that was normal between 2010 and 2021. Distributions to LPs came in at 14% of NAV in 2025, the fourth consecutive year below 15%.
So returns have to come from operations. In a software or software-enabled asset, operations means one thing: how fast and how safely the company can change its own product. That is the engine. Diligence inspects the paint.
The code audit stopped being a signal
Here is what broke the old method.
CloudBees surveyed more than 200 enterprise technology leaders for its 2026 State of Code Abundance report. AI now generates or assists 61% of the average enterprise codebase. In the same survey, 81% of leaders report an increase in production issues tied to AI-generated code, while 92% say they are confident in that code’s production readiness. Organisations could attribute only about one third of their AI spend to a specific business outcome.
Read those four numbers together. The majority of what a code audit now reads was written by a model. It is stylistically uniform, cheap to produce, and syntactically clean. A static scan of it comes back green. And the same leaders sitting on top of it report more incidents, not fewer.
The artefact and the risk have come apart. SonarQube can tell you the code is tidy. It cannot tell you whether this company can safely change it on a Tuesday afternoon with two engineers on leave.
Three things the standard scope misses
One: absorption capacity. The value creation plan lands with a dozen or more initiatives in the first year. ERP consolidation, pricing rebuild, a data platform, two integrations, a security remediation. The relevant question is not whether each is a good idea. It is how many concurrent initiatives this delivery system has ever finished in a single year. That number exists. It is in the last three years of shipped work. Diligence almost never asks for it.
Two: the review and approval path. Writing changes got cheap. Approving them did not. In most mid-market software businesses there are three or four people who can sign off a change to billing, entitlements or customer data. Their names are not in the diligence report. Their retention risk is the single largest technical risk in the deal, and it is usually filed under key person dependency with no measurement attached.
Three: the gap between the process document and the deploy log. Every data room contains a document describing how the company ships software. It is aspirational. The deploy history, the incident records and the pull request timestamps describe what actually happens. The distance between those two artefacts is the most predictive thing in the whole room, and reading it takes an afternoon.
I built D30 to pull three-statement fact files out of ASX annual reports and run articulation gates over them, because I do not trust a summary figure I cannot trace back to the filing that produced it. The instinct is identical here. A process document is a summary figure. The deploy log is the filing.
Where I am wrong
This thesis has real limits and I would rather name them than have a reader find them.
For asset-light businesses where software is a thin wrapper on a services model, the codebase genuinely is the risk, and licence contamination or a single hard-coded customer integration can be the whole finding. For a carve-out, the delivery system you measure belongs to the seller and will not survive separation, so measuring it tells you less than modelling what replaces it. And there are deals where the data simply is not available: a competitive process, a two-week window, no repository access, a seller who will not open the incident history. In that situation the code audit is not the wrong tool. It is the only tool you are allowed to use, and a good one done honestly beats a throughput analysis you invented.
The failure I am pointing at is not doing a code audit. It is doing a code audit and believing you have assessed delivery risk.
What I would do on Monday
Add one line to the diligence request list. The last 90 days of production deployments with timestamps, and the last 12 months of incidents with time to restore. Not the process document. The records.
Count the approvers. Ask who can approve a change to the revenue-critical paths. If the answer is fewer than four people, that is a retention clause in the SPA, not a footnote.
Divide the plan by the observed rate. Take the number of year-one initiatives in the value creation plan and compare it against the largest number of concurrent initiatives the company has actually completed in a year. If the plan is more than double, the plan is fiction and the EBITDA bridge is built on it.
Instrument in the first 30 days post-close. Jellyfish, DX and Swarmia all read from Jira and GitHub and give you a baseline inside a fortnight. Set that baseline before the operating partner starts changing things, or you will never know whether anything you did worked.
Re-underwrite once, at day 90. With real throughput data in hand, restate the operating case. Investors hate this. Doing it at month 18 instead is worse.
Back to the report
That two to four week technical diligence report will still get written on every one of the next $900 billion of deals. It is not useless. It is scoped for a market where multiple expansion did the heavy lifting and 5% growth was enough.
That market is gone. The number that has to double is produced by a system nobody in the room measured.
Buy the engine, not the paint.
I built D30 to pull three-statement fact files out of ASX annual reports and flag where the numbers stop articulating. If you run diligence on listed or pre-IPO assets, have a look.