By Mario Peshev, DevriX
Most tech due diligence reports I have read would not have changed the decision to buy. That is the problem. A deal partner reads a forty-page document full of architecture diagrams, framework inventories and severity-scored findings, and at the end of it still cannot tell you the one thing that matters: does the technology make this a better or worse asset to own, and what will it cost to fix what is broken. If the report does not move the price, the terms, or the 100-day plan, it was an expense, not diligence.
I have sat on both sides of this. I have built and run a firm that operates inside portfolio companies, and I have been the person a deal team calls when the technical read from a large advisory shop came back clean and the business still stalled after close. The gap is almost never in the depth of the technical analysis. It is in the translation. A CTO-for-hire can list every risk in a codebase. Very few can tell a deal partner which of those risks threaten the thesis, which threaten the model, and which are simply the normal state of a company that has been growing faster than its engineering discipline.
This piece is about what the buyer actually needs to decide, and how to judge whether the diligence you commissioned earned its fee.
The buyer is not buying software
Start from how a PE-backed buyer evaluates any technology question. You are not purchasing a codebase, a cloud bill, or a team of engineers. You are purchasing measurable enterprise-value improvement, and the technology is either a source of that improvement or a drag on it. Tech diligence exists to tell you which one you are looking at, and to size it.
That reframing changes what a good report contains. The engineering activity, the number of microservices, the test coverage percentage, the choice of framework, is context, not the answer. The answer is a set of financial and risk consequences: what the technology lets the business earn, what it will cost to keep earning it, what could break, and what the buyer will have to spend post-close to hit the plan.
I have written before that PE value creation requires embedded partners rather than advisory firms, and diligence is where that difference first shows up. An advisor documents the system. An operator tells you what owning it will do to your P&L.
Bain’s annual Global Private Equity Report has tracked, for several years running, how holding periods and value-creation expectations have shifted toward operational improvement rather than multiple expansion. When the plan depends on operating the asset better, the technology read has to be operational too. You can see the current view in Bain’s PE research hub.
Write the diligence for the person making the call
The single most common failure I see is a report written for no one. It is technically correct and commercially mute, because the author never decided who was reading it. The deal partner, the operating partner, and the CFO each need a different cut of the same findings.
The deal partner needs thesis, risk, and exit
A deal partner is not going to read a dependency graph. They need three things. Does the technology support the investment thesis, or quietly contradict it. What are the two or three risks large enough to change the price or the structure. And does anything in the technology stack make this asset harder to sell in four or five years. If the thesis is “consolidate five regional players onto one platform,” and the platform cannot support multi-tenancy without a rewrite, that is not a technical footnote. That is the deal.
The operating partner needs speed and a plan
The operating partner wants to know what happens in the first hundred days and whether the team can actually execute the value-creation plan. Can this engineering organization ship the roadmap the thesis assumes, or is half its capacity consumed keeping the lights on. This is where diligence should feed straight into the 100-day go-to-market plan for a newly acquired business, not sit in a separate binder.
The CFO needs it in dollars
The CFO wants technical risk expressed as cash and EBITDA. A looming cloud contract renegotiation, an under-provisioned security posture, a capitalized-versus-expensed engineering cost question, a key-person dependency that would cost real money to backfill. These belong next to the quality of earnings work, not buried in an appendix. If your tech diligence never once talks to the QoE, both are weaker for it.
The five questions that decide the deal
Strip away the format and tech diligence has to answer five questions. Everything else is supporting evidence.
Does the technology support the thesis, or fight it
The thesis makes an implicit demand on the technology. A buy-and-build assumes the platform can absorb acquisitions. A margin-expansion play assumes the technology can scale volume without scaling headcount and infrastructure at the same rate. A new-market thesis assumes the product can be localized, re-priced, or repackaged. Name the demand the thesis places on the stack, then ask whether the stack meets it. Most reports never state the demand, so they never test it.
What would it cost to fix the material weaknesses
Every company has technical debt. That is not a finding. The finding is which debt is material, meaning it threatens revenue, blocks the plan, or creates a real liability, and what remediation costs in money and calendar time. A number attached to a fix is diligence. A severity label without a cost is decoration.
Can the team execute the plan
Technology does not ship itself. The organization does. I have seen strong platforms in the hands of teams that could not deliver a roadmap, and mediocre platforms run by teams that shipped every quarter. Diligence has to assess capacity, key-person concentration, hiring realism in the local market, and whether the current leadership can operate at the scale the plan requires. This is the same discipline that shows up in a revenue leakage diagnostic, you are looking for the gap between what the model assumes and what the organization can actually do.
What are the real liabilities
Security exposure, license and open-source compliance, data-privacy handling, and undisclosed customer or contractual dependencies. These are risk-avoided items, and they belong in the reps and warranties conversation. The SEC has been increasingly explicit about cybersecurity disclosure obligations for public companies, and that standard sets the ceiling buyers should have in mind for anything they intend to take public or sell to a strategic. The current guidance lives on the SEC’s site.
Will it survive the hold and the exit
Whatever you buy, you will eventually sell. A stack that works today but will look dated to a strategic acquirer in four years is a different asset than one that will still be defensible. Frame at least part of the diligence around the exit, not just the entry. This is the same forward posture I argued for in future-proofing organizations.
How to judge the report you paid for
Here is the test I apply. Take the executive summary and ask whether it changes anything: the price, the structure, the reps, the 100-day plan, or the value-creation model. If it changes none of those, the diligence failed regardless of how thorough the technical section looks.
A few concrete markers separate real diligence from an expensive inventory.
- Findings carry a number. “Significant technical debt in the billing module” is not actionable. “Billing module rewrite, roughly two engineers for four to six months, blocks the pricing changes the thesis needs” is.
- Findings are ranked by business impact, not technical severity. A critical vulnerability in a system you plan to retire matters less than a moderate limitation in the platform the whole thesis rides on.
- The report distinguishes realized problems from forecast ones. “The system is down twice a week” is realized. “Will not scale past 10x current load” is a forecast, and it should be labeled as one, with the assumptions shown.
- It connects to the money. The tech read and the quality of earnings should reference each other. If the diligence treats capitalized software costs, cloud commitments, or engineering headcount as purely technical facts, it has missed half its job. Those feed adjusted EBITDA and the add-back conversation directly.
The consulting research on this is consistent. McKinsey’s private capital work and BCG’s principal-investor practice have both documented that value in the current environment comes disproportionately from operational execution rather than financial engineering, which raises the bar on diligence that actually informs the operating plan. You can find their ongoing coverage at McKinsey and BCG.
The activity trap, and why big-shop reports fall into it
Large diligence providers are paid to be thorough, and thoroughness reads as pages. So you get exhaustive coverage of every subsystem, weighted equally, because equal weighting is defensible and prioritization is a judgment call someone has to own. The result is comprehensive and useless. Two hundred findings with no view on which five matter is not a decision aid, it is a liability shield for the firm that wrote it.
This is the same distinction I keep drawing between value-creation consultants and operators with P&L accountability. The consultant is optimizing to not be wrong. The operator is optimizing to be useful, which means taking a position. When I review a stack for a deal team, I would rather be held to five prioritized calls with cost estimates than hide behind an exhaustive list I can never be blamed for. This is a well-documented pattern in the deal literature; the Harvard Business Review’s M&A coverage has long argued that diligence which takes a defensible position beats diligence that merely catalogs.
Prioritization requires someone who has actually operated the kind of business you are buying. That is not a knock on technical auditors. It is a different job. Reading a codebase tells you what exists. Knowing which parts of it will hurt a company trying to double revenue in a mid-market B2B setting requires having run that company, or one close enough.
Where tech diligence meets commercial diligence
The best signal in a tech read often comes from outside the code entirely. If churn is climbing, the technology may be the cause, product instability, missing features, slow delivery, and the commercial numbers will show it before any code review does. If sales cycles are lengthening, the product may be falling behind on the features that close deals.
This is why tech diligence should never run in isolation from the commercial work. Many of the commercial due diligence red flags in B2B businesses have technical roots, and many technical risks only become material because of a commercial fact. A performance limitation that would be irrelevant in a flat business is a serious problem in a business the thesis says will triple in volume.
The same logic applies to the go-to-market engine. When I have brought in fractional commercial leadership to fix win rate and CAC, the technical constraints on the product almost always show up in the pipeline data first. Diligence that reads the tech and the commercial signals together catches things that either read alone would miss. It also keeps the deal team out of the common GTM value-creation pitfalls that come from assuming the product can support a growth plan it was never built for. Deal-volume and sector data from sources like PitchBook make the point plainly: the businesses that clear diligence cleanly are the ones where the commercial and technical stories agree.
What the buyer should walk away with
A tech diligence engagement that earns its fee produces a short set of outputs, not a long report. You should end with:
- A one-page view of whether the technology supports or threatens the thesis, stated plainly.
- A ranked list of material issues, each with a cost and a timeline to fix.
- A read on the team’s ability to execute the plan, with named key-person risks.
- A liabilities summary that feeds the reps and warranties and the QoE.
- A first draft of the technical portion of the 100-day plan, so diligence flows into action instead of stopping at the deal.
Everything else is supporting evidence you keep on file. If the engagement gives you those five things, it changed how you buy the company or how you run it after close. That is the only test that matters.
The operator takeaway
Tech diligence goes wrong when it is scoped as a technical audit and reported to no one in particular. Scope it as a decision aid, name the reader, and demand that every finding connect to the thesis, the money, or the plan. The best diligence I have seen was shorter than the worst, because someone was willing to prioritize, put costs on the fixes, and take a position. That willingness to be accountable for a judgment, rather than exhaustive and useless, is the same thing that separates advisors from operators everywhere else in the deal.
If the technology under diligence is going to be operated hard during the hold, the people reviewing it should be the kind of people who could operate it. That is not always the case with a traditional technical audit. It should be your default assumption when the plan depends on the product doing more than it does today. The commercial KPIs you will manage against post-close, the ones I outline in portfolio company operating reviews, all have technical dependencies you want surfaced before you sign, not after.
Where DevriX fits
DevriX runs Deal-Moment Diligence for PE deal teams and operating partners: a tech read written for the person making the call, connected to the quality of earnings and the value-creation plan, and delivered by people who operate mid-market B2B technology rather than only audit it. We give you the five outputs above, ranked and costed, in time to matter for the price and the terms.
If you have a deal in front of you and want the technical read to actually inform the decision, start an advisory exploration with me here, or review the full range of DevriX services to see how the diligence work carries into the first hundred days after close.
