By Mario Peshev, DevriX
You are three weeks from signing, the QoE looks clean, the growth story holds, and the only thing standing between you and a confident IC memo is a software platform you cannot see inside. The management team says the product is “mature and scalable.” The CTO gives you a demo, not a system. And the diligence provider you are considering wants to run a code audit that produces a 40-page report nobody on the deal team will read before close. That is the wrong problem. Software due diligence for private equity is not a code review. It is a decision-support exercise. You need to know whether the technology supports the thesis, whether it will survive the hold period, and where the money and risk are actually buried before you price the deal or build the plan.
This piece is for the deal partner and operating partner who already have budget and a live process. It is about what to decide, what evidence forces those decisions, and how to tell a serious assessment from an expensive PDF.
The four questions a deal partner is actually paying to answer
Strip away the vendor jargon and every software diligence exercise you commission is trying to answer four questions. Everything else is supporting detail.
- Does the technology support the investment thesis? If your model assumes the platform absorbs three add-ons, doubles seat count, and moves upmarket, the software has to be capable of that. If it cannot, your thesis is fiction.
- What will it cost to get where the plan needs it to go? Not “is the code good.” What capital and calendar time stand between the current state and the state the value creation plan assumes.
- What could blow up during the hold? Key-person dependency, an unsupported core dependency, a security exposure, a licensing landmine, a single customer running on a fork nobody maintains.
- Who owns this after Day 1, and can they execute? The org chart matters more than the architecture diagram. A clean codebase run by a team that quits at close is worse than a messy one run by people who will stay.
Notice that none of these are answered by a line count, a test-coverage percentage, or a list of frameworks. Those are inputs. The output you are buying is a set of priced, owned decisions. Bain’s annual private equity report has tracked how value creation has shifted from financial engineering toward operational improvement over successive cycles, and you can read that thesis in Bain’s Global Private Equity Report. Operational improvement runs on systems. That is exactly why the software assessment has moved from a checkbox to a pricing input.
What a serious assessment produces, and what a weak one produces
The single fastest way to judge a diligence provider is to ask what artifact they hand you and who on your team can act on it. A weak engagement produces a document. A serious engagement produces decisions.
The weak output
You have seen it. A long report organized by technical category, heavy on findings, light on consequence. It tells you the database is Postgres and the test coverage is 62 percent. It rates things red, amber, green with no dollar figure attached to the reds. It never says whether the reds threaten your thesis or merely annoy an engineer. The deal team skims the executive summary, files it, and prices the deal on gut anyway. You paid for coverage, not for a decision.
The output worth paying for
A useful software diligence deliverable reads like a risk register a CFO could underwrite. Every material finding carries four things: what it is, what it costs to fix or contain, when it bites during the hold, and who owns it. It ties directly to the model. If the plan assumes a platform migration to enable the SaaS transition, the assessment prices that migration and flags the dependencies that could slip it. It translates engineering reality into EBITDA and integration terms, which is the whole point of technology due diligence in a PE context. I have written before about why translating engineering into P&L language is the job, not a nice-to-have, in the piece on aligning engineering, product, and RevOps for PE value creation.
Software diligence for private equity has to price the value creation plan, not just the risk
Most providers default to defense. They hunt for what could go wrong. That is necessary, but it is half the job and often the less valuable half. The reason you commissioned software due diligence for private equity, rather than a generic security audit, is that you have a thesis with specific technical dependencies, and you need to know whether the platform can carry it.
Take a typical mid-market thesis: buy a vertical SaaS business, bolt on two competitors, consolidate onto one platform, cross-sell the combined base, exit in five years at a higher multiple. Every clause in that sentence is a technical bet.
- Bolt on two competitors means the platform has to absorb acquisitions. Is the data model multi-tenant or single-tenant per customer? Can it onboard an acquired book without a two-year rebuild?
- Consolidate onto one platform means one of the three codebases becomes the survivor. Which one, and what does killing the other two cost and take?
- Cross-sell the combined base means the systems have to share customer data. If billing, CRM, and product live in three disconnected worlds, cross-sell is a slide, not a capability.
- Exit at a higher multiple means a buyer’s diligence in year five has to pass. What you tolerate at entry, the next buyer marks you down for at exit.
A software assessment that does not read your model and price these dependencies is not doing PE diligence. It is doing a generic technical review that happens to be paid for by a fund. That distinction is why I keep arguing that PE value creation requires embedded partners, not advisory firms: the people who assess the platform should be able to imagine building the plan, because they are the ones who will be asked to.
The findings that actually move a decision
After enough of these, you learn that a handful of finding types carry almost all the decision weight. The rest is noise you can tune out. Here is where I focus attention.
Concentration and key-person risk
The most expensive thing you can discover post-close is that the entire platform lives in one person’s head. Not the org chart version, the real version. Who is the one engineer who can deploy to production without breaking it? Who wrote the billing engine and never documented it? Concentration risk is a retention problem, a compensation problem, and a Day 1 problem all at once. It rarely shows up in a code metric. It shows up in a conversation, if the assessor knows how to have one.
Scalability against the plan, not in the abstract
“Can it scale” is a meaningless question. “Can it handle the seat count and transaction volume the model assumes in year three, on the current architecture, without a rewrite” is a decision. The answer is either yes, yes-with-investment-of-X, or no-and-here-is-the-rebuild. Only the last two change your number.
Security and compliance exposure that a buyer or regulator will act on
Not a theoretical vulnerability list. The exposures that create real liability or block the exit. If the business handles regulated data and has no meaningful controls, that is a covenant risk and a valuation risk, not a to-do item. The Harvard Law School Forum on Corporate Governance regularly publishes on how cyber and data governance failures translate into board-level and deal-level consequences, which is the register this belongs in.
Technical debt with a price and a trigger
All software has debt. The question is which debt is inert and which debt is on a timer. A dependency that goes end-of-life in eighteen months, inside your hold period, is a dated liability. A messy but stable module that nobody has to touch is a footnote. A good assessment separates the two. A bad one lists all of it with equal alarm and lets you assume the worst.
Pre-LOI versus confirmatory: match the depth to the decision
One reason software diligence gets a bad reputation is that funds run the wrong depth at the wrong time. You do not need a full confirmatory assessment to decide whether to bid. You need a fast read on whether there is a fatal flaw before you spend real diligence dollars.
Before the LOI
Pre-LOI, the decision is binary and cheap: is there anything here that kills the deal or resets the price. A tight, focused check answers that in days, not weeks. You are looking for the platform equivalent of a cracked foundation. A lightweight pre-LOI technology check exists precisely to keep you from either overpaying for a broken asset or walking away from a fixable one for the wrong reason. At DevriX we structure this as a $5K pre-LOI check that credits into the full engagement if you proceed, so you are not paying twice for the same knowledge.
Confirmatory, before you sign
Once you are under LOI and pricing risk into the deal, you need the full read: the priced value creation plan, the risk register, the key-person map, the integration dependencies. Our 5-Day Tech DD at $15K is scoped to produce exactly that inside the window most confirmatory processes allow. The output is not a report you file. It is a document your deal team argues over in IC and your operating partner builds the first 100 days from.
PitchBook and other data providers have documented how deal timelines have compressed and diligence windows have tightened across the mid-market, and you can follow that trend through PitchBook’s research. Compressed timelines are exactly why matching diligence depth to the decision matters more now than it did a decade ago. You cannot afford a six-week code audit when you have five days.
Why the assessor’s identity changes the answer
The same platform assessed by three different providers produces three different reports. A security firm finds security problems. A code-audit shop finds code smell. A team that has built and run software at scale finds the two or three things that will actually cost you money or time during the hold. This is not a knock on any specialty. It is a reminder that you are hiring a point of view, and the point of view should match the decision you are financing.
The distinction I care about most is between assessors who only advise and assessors who could actually execute the plan they are pricing. When someone knows they might have to own the migration they just estimated, the estimate gets honest fast. I have made this case at length in the difference between value creation consultants and operators with P&L accountability, and in why technical value creation partners operate inside portfolio companies rather than hand over slides. A software assessment written by someone who will never touch the system tends to hedge. A software assessment written by someone who might inherit it tends to commit.
There is a governance dimension here too. Diligence-stage advice and hold-stage building are different roles, and confusing them creates conflicts you do not want. I separated those roles deliberately in the piece on board technology advisors and the line between governance and hands-on builds. For diligence, you want an assessor with builder judgment and no incentive to inflate the remediation budget. For the hold, you want permanent embedded digital capacity, not another advisory retainer.
How to read the report the deal team hands you
Assume you have commissioned the work and the deliverable lands on your desk 48 hours before IC. Here is how I read one quickly to decide whether it is trustworthy.
- Go to the risks and look for dollars and dates. If the reds do not carry a cost estimate and a hold-period timing, the assessor did not finish the job. A risk without a price is not a decision input.
- Check whether it read your model. A generic report never mentions your specific thesis. A real one references the add-on strategy, the seat-count assumptions, the exit timeline. If the platform findings are not mapped to the plan, treat the whole thing as background reading.
- Find the key-person section. If it does not exist, the assessor talked to systems and not to people. The most expensive risks in software are human.
- Look for what they recommend you do in the first 100 days. A report that ends at “here are the problems” leaves the hardest work undone. A report that hands your operating partner a sequenced starting plan is worth several times the fee.
- Notice what they refused to conclude. Good assessors state clearly what they could not verify in the time and access they had. False confidence is a warning sign. McKinsey’s writing on private capital and value creation repeatedly returns to the gap between diligence assumptions and operating reality, and honest assessors flag where that gap sits rather than paper over it.
The operator takeaways
If you remember nothing else from this, remember these five moves. They will save you more than the price of any single engagement.
- Commission decisions, not documents. Tell the assessor up front that you want priced, owned findings mapped to your thesis, not a category-by-category audit. If they cannot deliver that, they are the wrong provider.
- Match depth to the decision. A pre-LOI check to avoid a fatal flaw. A full assessment before you sign. Do not run a two-week code audit to make a bid decision, and do not sign on a one-day skim.
- Hire builder judgment. The most useful assessor is one who could run the remediation they just priced, because that is the person whose estimate you can trust.
- Read for dollars, dates, and owners. Any finding without those three is a fact, not a decision. Send it back.
- Bridge diligence into the plan. The output should hand your operating partner a sequenced first-100-days starting point. If it stops at “here are the risks,” you paid for half the value. I laid out the common gaps between diligence and execution in the piece on avoiding value creation pitfalls in private equity GTM.
Software due diligence for private equity earns its fee when it changes what you pay, what you plan, or whether you walk. If it does none of those, it was theater. The market has moved this from optional to structural precisely because so much of mid-market value creation now depends on whether the platform can carry the thesis. BCG and S&P Global have both documented the growing weight of technology and operational levers in returns, and you can trace that through BCG’s principal investors work and S&P Global Market Intelligence. The funds that treat software diligence as a decision exercise, not a compliance step, are the ones who stop overpaying for broken platforms and stop walking away from fixable ones.
Where to take this next
If you have a live deal and need a read on whether the platform supports your thesis, that is exactly what our private equity technology practice is built to deliver, either as a $5K pre-LOI check to catch a deal-killer early, or a $15K 5-Day Tech DD that hands your deal team a priced value creation plan and your operating partner a first-100-days starting point. Bring us the thesis and the timeline, and we will tell you what the technology can actually carry.
