By Mario Peshev, DevriX
You are three weeks from signing an LOI, or you have signed and confirmatory diligence is running hot, and someone hands you a 40-page technical report. It is dense with CVE counts, framework versions, a cloud spend breakdown, and a diagram of the deployment pipeline. None of it tells you the one thing you actually need: does the technology under this business change the price, the plan, or the walk decision. That is the failure mode of most technical work sold to deal teams. It documents the estate. It does not inform the decision you are being paid to make.
An IT diagnostic for private equity is not a systems audit dressed for a boardroom. It is a decision instrument. It exists to answer a small number of commercial questions with evidence, ranked by consequence, owned by a named person, and delivered on the clock your process is running on. If the report you receive cannot be read by a deal partner in fifteen minutes and turned into a term, a condition, or a Day 1 action, it failed, no matter how thorough the appendix is.
This piece lays out the framework I use to structure that diagnostic and, just as importantly, how to judge one you have already commissioned. If you are evaluating a target now, use it as a scorecard against whatever landed on your desk.
1. The four questions a diagnostic exists to answer
Strip away the tooling and every technology diagnostic in a deal context is answering four questions. Everything else is supporting evidence.
- Does the technology support the thesis? If your model assumes 3x revenue on the same headcount, or a bolt-on acquisition every nine months, can the platform actually carry that load without a rebuild you have not priced?
- What breaks in the first 100 days? Key-person dependency, an expiring contract, an unsupported database, a security exposure that a buyer now owns. These are the surprises that eat the honeymoon.
- What does it cost to fix, and when does the bill land? Not a vague “there is tech debt.” A dollar range, a timeline, and whether it is a Day 1 emergency or a Year 2 line item.
- Who owns delivery? Is there anyone inside the company who can execute the fix, or are you buying a team you will have to build or replace?
If a report does not map cleanly to those four, it is describing plumbing. Bain’s annual Global Private Equity Report has tracked for years how value creation has shifted from financial engineering toward operational improvement, and technology sits squarely in that shift. The diagnostic has to speak that language or it is not doing the job the deal requires.
2. Name the framework: the Decision Diagnostic
I call the structure a Decision Diagnostic to keep the emphasis where it belongs. It has three tiers, run in order, each gating the next. You do not go deep on tier three until tiers one and two have told you the deal is worth the depth.
Tier 1, Thesis fit
This is the go/no-go layer. Can the technology carry the value-creation plan you underwrote? A platform that was fine as a founder-run SMB may be structurally incapable of the buy-and-build you have in mind. This tier is fast, senior, and blunt. Its output is a single judgment: green, yellow with conditions, or red.
Tier 2, Risk and cost quantification
Once the thesis survives, you quantify the exposure. Security, compliance, key-person concentration, licensing, hosting cost, and the specific debt that will slow the plan. Each item gets a severity, a rough cost band, and a timing bucket. This is what feeds a price adjustment or a set of closing conditions.
Tier 3, Ownership and executability
The last tier is about people and delivery. Who can actually do the work? Is the CTO a keeper or a Day 1 replacement? Does the roadmap require capacity the portfolio company does not have and cannot hire in time? This is where a diagnostic either hands you a plan someone is on the hook to run, or leaves you with a wish list.
The tiers matter because they enforce proportion. Deal teams waste money on exhaustive tier-three detail for targets that fail tier one. Run it in order and you spend your diligence budget where the decision actually turns.
3. What Tier 1 looks like when it is done right
Thesis fit is the tier most reports skip, because it requires the assessor to actually understand your investment case, not just the codebase. A vendor who never asks about your hold period, your revenue model, or your add-on pipeline cannot assess fit. They can only assess the estate against a generic checklist.
Done right, tier one reads your model back to you and stress-tests the technology against it. If the plan is a roll-up, the question is integration: can this platform absorb three acquisitions without a data migration that consumes the whole synergy case? If the plan is margin expansion through automation, the question is whether the architecture allows it or forces a re-platform first. This is the same discipline behind aligning engineering, product, and RevOps for value creation: technology is judged against the commercial outcome it has to produce, not against best-practice orthodoxy.
The output of tier one should fit on a slide. Green, yellow, red, with the two or three reasons behind the color. A deal partner should be able to read it and decide whether to keep spending on tiers two and three or redirect the budget.
4. Turning Tier 2 findings into price and terms
This is the tier that pays for the diagnostic. Findings that are not quantified are opinions, and opinions do not move a purchase agreement. A usable tier-two finding has four attributes: what it is, how bad it is, what it costs to remediate, and when the cost hits.
Consider an illustrative example. A target runs on a database version that reaches end of support four months after your expected close. The finding is not “outdated infrastructure.” It is: unsupported database, high severity because it carries a compliance and security exposure the moment you own it, remediation band of roughly two to four months of engineering effort, and timing that makes it a Day 1 workstream, not a someday item. That is a finding you can price. It becomes a purchase-price consideration, an indemnity conversation, or a funded line in the first 100 days plan.
McKinsey’s private capital research and BCG’s work on principal investors and private equity both keep returning to the same theme: the returns are increasingly made in operations, and unpriced operational risk is where deals underperform their models. A tier-two finding that never crosses into the dollar column is a finding that did nothing.
5. Tier 3 and the question of who is on the hook
The most expensive surprises after close are rarely lines of code. They are people. A brilliant platform maintained entirely by one contractor who has no incentive to stay is a Day 1 crisis wearing the costume of a healthy asset. Tier three surfaces this before it becomes your problem.
The assessment covers three things: key-person concentration, the gap between the team you are buying and the team the plan needs, and whether leadership can be trusted to run the roadmap or has to be supplemented. This is where the distinction between advice and delivery gets real. There is a large difference between a consultant’s advice you can ignore and a plan someone is contractually on the hook to deliver. A diagnostic that ends at “you should hire a CTO” has diagnosed nothing you did not suspect. One that tells you whether the existing CTO clears the bar, and what the interim coverage costs if they do not, has done the work.
For many mid-market targets, the honest tier-three answer is that the company cannot execute its own roadmap with the team in place. That is not a reason to walk. It is a reason to plan for coverage. A virtual CIO arrangement gives a portfolio the coverage it needs without a full-time hire the platform cannot yet justify, and a part-time CTO seat enforces the decision rules that a leaderless engineering function will otherwise drift without.
6. How to judge a diagnostic you have already been handed
If you commissioned a report and want to know whether it earned its fee, run it against this checklist before your next investment committee meeting.
- Can a non-technical partner read the summary and act on it? If it requires an engineer to translate, it was written for the wrong reader.
- Does every material finding carry a cost band and a timing bucket? No dollars, no timing, no decision.
- Is there a clear tier-one verdict? A report with no go/no-go stance is hedging, not advising.
- Does it reference your actual thesis? If it never mentions your hold period, add-on plan, or revenue model, it assessed a generic company, not your deal.
- Does it name owners and interim coverage costs? Findings without a delivery owner are homework you still have to do.
- Was it delivered on your clock? A perfect report that lands after your exclusivity window closes is worthless.
A report that clears all six is rare. A report that clears fewer than three is a document you paid for and cannot use. The Harvard Law School Forum on Corporate Governance has published extensively on diligence discipline in M&A, and the recurring lesson is that diligence quality is measured by the decisions it enables, not by page count.
7. Matching depth to the stage of your process
Not every deal needs the same depth, and paying for confirmatory-grade diligence on a target you have not yet gotten under LOI is a poor use of budget. Two stages, two products.
Pre-LOI screen
Before you commit exclusivity, you want a fast tier-one read and a first pass at the obvious tier-two risks. A lightweight pre-LOI screen tells you whether the technology is a reason to move forward, hold price, or pass, without a full teardown. This is a low-cost decision gate, and its whole value is preventing you from spending real diligence money on a deal that fails at tier one.
Confirmatory technical diligence
Once under LOI, the five-day technology due diligence engagement runs all three tiers to depth, produces the priced findings that feed your purchase agreement, and hands you a delivery-owned plan for Day 1. This is the report that changes terms and de-risks the first 100 days.
PitchBook’s research and data and S&P Global Market Intelligence both track how compressed deal timelines have become in competitive mid-market processes. Matching diagnostic depth to stage is how you stay fast without flying blind.
8. An applied walk-through
Here is how the framework runs on an illustrative mid-market SaaS target, hold thesis of buy-and-build with two add-ons planned in the first eighteen months.
Tier 1. The assessor reads the thesis and stress-tests it. The platform is a single-tenant architecture, which means every add-on requires a bespoke integration rather than a repeatable onboarding. Verdict: yellow. The thesis is achievable but the integration cost the model assumed is understated. That single finding is worth more than the entire security appendix, because it hits the core value driver.
Tier 2. Quantification surfaces three material items: the single-tenant integration cost (roughly one quarter of engineering capacity per add-on), an expiring hosting contract with a price step-up, and a set of unpatched dependencies that are medium severity, Year 1 remediation. Each gets a band and a timing bucket. Two of them adjust the model directly.
Tier 3. The engineering team is competent but has never run an integration. There is no head of engineering, only a lead developer. The honest read is that the roadmap needs senior technical leadership the company does not have. The recommendation is interim coverage from Day 1, not a nine-month executive search that leaves the first two add-ons rudderless. This is exactly the argument that value creation requires embedded partners, not advisory firms, and that technical value-creation partners operate inside the portfolio company rather than filing a report and leaving.
The deal partner now has three things a stack of CVE data could never provide: an adjusted integration cost that feeds the model, two conditions to negotiate, and a Day 1 leadership plan with a named owner and a monthly cost. That is a diagnostic that changed the deal.
9. Where the diagnostic connects to the value-creation plan
A diagnostic that ends at close has done half its job. The findings, owners, and cost bands should flow straight into the value-creation plan the board will hold management to. The tier-two risk register becomes the first section of the technology workstream. The tier-three coverage recommendation becomes a staffing line. There is a reason we claim ownership of the value-creation plan as the connective tissue between diligence and execution: the diagnostic is where that plan starts, not a separate exercise that gets shelved after signing.
This is also why the debate between embedded versus advisory capacity matters for a portfolio. A report from a firm that disappears at close leaves you to translate findings into action alone. A diagnostic run by a partner who can also deliver the remediation means the tier-two register already has a delivery owner. Governance and hands-on delivery are different jobs, as the split between board technology advisors and hands-on builds makes clear, and a good diagnostic tells you which of the two each finding requires.
10. Conclusion
An IT diagnostic for private equity is judged on one thing: whether it changed a decision. Not on its length, its tooling coverage, or the sophistication of its architecture diagrams. Run the Decision Diagnostic in tiers, thesis fit first, quantified risk second, ownership last, and demand that every finding carry a cost band, a timing bucket, and a named owner. Match the depth to your stage, a pre-LOI screen before exclusivity and a full confirmatory teardown once under LOI. And insist that the findings flow into the value-creation plan rather than dying in an appendix.
The reports that fail deal teams are the ones written for engineers and read by no one who makes the call. The ones that earn their fee read like a term sheet input, because that is what they are.
If you have a target under LOI or approaching one and need a diagnostic built to change terms and de-risk Day 1, our private equity technology practice runs the 5-Day Tech DD and the Pre-LOI screen against the exact framework above. Bring us the thesis and the timeline, and we will tell you what the technology does to both.
