By Mario Peshev, DevriX
If you are sitting between an LOI and a confirmatory close, the technology work in front of you is a set of decisions that change the number you are willing to pay, the integration budget you carry into the model, and the risk you accept on the exit clock. A deal-driven IT strategy in private equity answers a specific question: given this thesis and this hold period, what has to be true about the technology, and what will it cost in cash and time to make it true?
I have watched deal teams treat the technical workstream as a compliance box, a report that arrives late, gets skimmed for red flags, and never touches the model. That is money left on the table and risk carried blind. The point of the exercise is to inform a decision, so the first move is naming the decisions.
The four decisions technology diligence is supposed to inform
Most of the confusion around technology due diligence comes from treating it as a research project instead of a decision input. A deal partner and an operating partner need different things from the same evidence, and both need it tied to a number.
There are four decisions worth the spend. First, does the technology support the growth thesis, or does it cap the revenue plan before you start. Second, what is the integration cost and timeline, in real money and real months, that belongs in the model. Third, where is the operating risk that could produce a covenant miss or a forecast blow in the first year. Fourth, what is the run-rate cost of keeping the lights on, and how much of that is deferred spend the seller has been quietly avoiding.
Everything a technical adviser hands you should map to one of those four. A finding that does not change a decision is trivia, and trivia at diligence prices is a bad trade.
Start from the thesis, then look at the stack
The mistake I see repeated is starting from the architecture diagram and working outward. That produces a tidy document about microservices and cloud spend that nobody in the deal room can act on. Start from the thesis instead, because the thesis tells you which parts of the stack matter and which parts you can leave alone.
If the thesis is a roll-up, the questions are about integration cost, data portability, and whether the target’s systems can absorb three more acquisitions without a rebuild. Bain’s annual global private equity report has tracked how much of recent value creation has leaned on operational improvement rather than multiple expansion, and integration capability sits underneath a lot of that operational work. If the thesis is organic growth into a new segment, the question is whether the product can scale to the customer count without the engineering team doubling, as the model requires.
A stack that is perfectly fine for a lifestyle business at its current size can be the single biggest constraint on a plan that triples revenue in four years. You only know which case you are in by holding the technology up against the specific plan, not against a generic maturity benchmark.
What the deal partner actually needs to see
A deal partner does not need to understand the codebase. The deal partner needs three things translated into the language of the model: what the technology adds to or subtracts from the growth case, what it costs to fix the gaps, and which findings carry enough risk to change the price or the structure.
I have written before about what a deal partner actually needs from a consultant, and the short version applies here. The adviser’s job is to convert engineering reality into commercial consequence. A finding like “the platform runs on an unsupported framework version” is useless on its own. The useful version reads: “the platform runs on a framework that loses vendor support in fourteen months, the migration is roughly a two-quarter engineering effort, and until it lands you carry a security exposure that will show up in your own diligence when you sell.”
That second version has a cost, a timeline, and an exit implication. It belongs in the model. The first version belongs in a drawer.
What the operating partner needs is different
The operating partner inherits whatever the diligence missed. So the operating partner reads the same evidence looking for execution risk: can the current team deliver the plan, what has to be hired or replaced, and what breaks on Day 1 if you touch the wrong system too early.
This is where the first 100 days plan gets written, and it gets written badly when nobody separated the urgent from the important during diligence. The urgent items are the ones that fail without intervention: an expiring contract, a single engineer who holds the only knowledge of the billing system, a data migration that has to happen before the seller’s transition services agreement expires. The important items can wait a quarter.
I covered the mechanics of this handoff in more detail in a piece on what IT integration actually decides in an M&A deal, and the through-line is the same: the value is created or destroyed in the sequencing, not in the technology choices themselves.
[Image to add: Diligence Findings, Sorted by When They Bite | a 4-tier stack labeled top to bottom: "Day 1 must-fix (TSA expiry, single points of failure, ]
The run-rate and deferred spend nobody wants to surface
Sellers manage EBITDA in the year before a sale, and technology is one of the easiest places to do it quietly. Deferred hardware refreshes, skipped license true-ups, an engineering team run below its real needs, a monitoring tool that lapsed. None of it shows up as a line the CFO flags, because the whole point was to keep it off the radar.
A deal-driven IT strategy in private equity has to surface this, because it feeds directly into forecast reliability. If the target has been underspending on technology by a meaningful amount, that spend returns after close, and it returns as a hit to the very EBITDA number the price was built on. McKinsey’s work on private capital and operational value creation has repeatedly made the point that the gap between the entry model and the first-year actuals is where a lot of deals lose their planned return, and deferred technology spend is a common and preventable source of that gap.
The number you want out of diligence is a normalized run-rate: what the technology actually costs to operate at the level the plan requires, not the level the seller trimmed it to. That number rarely equals the trailing spend, and the difference belongs in your model as a cash adjustment, not a surprise in month eight.
How to judge the adviser you hire for this
The market for technical diligence is crowded, and a lot of it produces the drawer document I described earlier. Here is how I judge the work, whether it is my team or someone else’s.
They ask about the thesis before the stack
A good adviser wants to see the model, or at least the growth plan, before they open a single repository. An adviser who starts with an architecture questionnaire and never asks what you are trying to do with the business will hand you a maturity assessment, which is not what you paid for.
Every finding carries a number and an owner
A finding needs an estimated cost, a rough timeline, and a named place it lands in the model before you can use it. This is the same discipline I described in what a deal partner needs from a consultant: the deliverable is a set of decisions with evidence attached, which means every observation has to connect to something you can act on with a number and a date.
They tell you what they could not confirm
Pre-LOI, access is thin and the seller is guarded. An honest adviser tells you which conclusions are firm, which are inferred from limited access, and which have to be re-tested in confirmatory diligence with real system access. The ones who present everything at the same confidence level are the ones who miss things. The Harvard Law School Forum on Corporate Governance has published extensively on diligence process and disclosure risk, and the recurring theme is that unstated assumptions, not wrong facts, cause the expensive surprises.
Where the money maps to the timeline
The commercial reason to phase this work is that your access and your certainty both increase as the deal progresses, and you should not pay for depth you cannot yet get. Pre-LOI, you are pressure-testing the thesis with limited access, and a tight engagement in the range of a few thousand dollars can tell you whether the technology is a reason to walk, a reason to adjust price, or a non-issue.
Confirmatory diligence is where a fuller engagement earns its keep, because you now have real access and the cost of being wrong is the whole deal. A five-day technical diligence sprint in the mid-five-figure range is cheap insurance against a seven or eight-figure integration surprise. PitchBook’s deal and diligence data shows how much integration cost overruns and delayed synergy capture drag on realized returns, and most of that overrun traces back to something a diligence sprint would have flagged.
The findings that should change the deal, not just the report
A diligence exercise has done its job when at least one of these things happens: the price moves, the structure changes, the integration budget in the model gets bigger, or a specific item lands on the Day 1 list with a named owner. If the report arrives, gets read, and nothing in the deal changes, then either the technology genuinely carried no consequence, which is rare, or the work failed to connect its findings to the decisions.
The data findings deserve their own note here. I have written about why sponsors rarely get a number they trust from portfolio companies, and it usually starts with a data architecture that was never built to produce clean reporting. If you discover in diligence that the target cannot produce a reliable customer count or a clean revenue-by-segment breakdown without manual work, that is not a minor finding. It caps your visibility for the entire hold and it makes board reporting that drives decisions a first-year build rather than a given.
For a roll-up specifically, the technology findings compound, because you are not judging one stack, you are judging whether the platform can absorb the ones you have not bought yet. I laid out the mechanics of that in a piece on what a roll-up’s website consolidation actually buys you, and the same logic runs through every shared system in a buy-and-build.
Common failure modes worth naming
The report that arrives after the decision is the most common one. Diligence timed to land after the investment committee has already formed its view is theater. The work has to be sequenced so its findings reach the model while the model can still change.
The second failure is the adviser who cannot separate their own preferences from the deal’s requirements. An engineer will always find a way the stack could be better. That is not the question. The question is whether the stack supports this plan at this size for this hold period, and a good adviser stays disciplined about that scope even when they personally would rebuild half of it.
The third is treating the technical and the commercial diligence as separate documents that never reconcile. The revenue quality of earnings and the technical findings have to agree on the same underlying reality. When the team writing the QoE assumes a customer growth curve the platform cannot serve, someone has to catch that before close. I have argued elsewhere, in a piece on what RevOps consulting actually needs to decide in a deal, that the systems behind the revenue number are as much a part of diligence as the number itself.
What good looks like at the first board meeting
The test of a deal-driven IT strategy is what the operating partner walks into the first board meeting holding. If the technology workstream did its job, the operating partner has a prioritized list with owners and dates, a normalized run-rate that already sits in the budget, and a clear view of which two or three items carry real risk in year one.
If instead the operating partner spends the first quarter rediscovering what diligence should have told them, the deal already lost time it will not get back. The first 100 days are the most expensive quarter of the hold to waste, because everything that slips there slips against a fixed exit date. Managing the handoff well is most of what separates a post-merger integration consultant worth backing from one who bills through the confusion.
The short version for a deal team
Name the four decisions before you commission anything. Start from the thesis, not the architecture. Insist that every finding carry a cost, a timeline, and a place in the model. Surface the deferred spend the seller buried, and phase the depth of the work to match your access and the cost of being wrong. The whole exercise should be judged by whether it changed a decision, because changing a decision is the only reason to run it.
Technology in a deal is a lever on enterprise value, on the price you pay, on the integration budget you carry, and on how confidently you can forecast the first year. Treated as a decision input, a deal-driven IT strategy earns its cost several times over. Treated as a compliance report, it is a line item that protects no one.
If you are approaching an LOI or a confirmatory close and want the technical workstream run as a decision input rather than a filed document, look at how the DevriX private equity team structures pre-LOI and five-day technical diligence, and bring us the thesis before the stack.
