By Mario Peshev, DevriX
Most technical diligence reports I have read on behalf of PE buyers would not change a single decision if you deleted them from the data room. They catalog the estate. They count servers, list frameworks, flag some out-of-date libraries, and hand you a risk register with forty items color-coded red, amber, and green. None of it tells the deal partner the one thing they are paying for: does the technology in this business support the thesis, or quietly work against it?
I have sat on both sides of this. I have run the vendor engineering for portfolio companies post-close, and I have been the person a deal team calls three weeks before signing to ask whether the platform they are about to buy is a growth asset or a liability wearing a growth asset’s clothes. The gap between a useful technical checklist and a useless one is not depth. It is whether every finding gets translated into money, time, or risk that a partner can act on.
What follows is the checklist I actually work from, reorganized around the decision each item feeds. Read it as a buyer with budget, not as an engineer. Every section answers one question: what would this cost you, when, and does it move the thesis.
1. Start With the Thesis, Not the Stack
Before anyone opens a repository, I want one paragraph from the deal partner: what is this business supposed to become, and what does technology have to do to get it there. A roll-up thesis needs integration capacity. An organic-growth thesis needs the product and go-to-market engine to scale without the cost line scaling with it. A margin-expansion thesis needs the technology to stop consuming cash it does not need to.
The reason this comes first is simple. A stack that is perfectly adequate for a standalone hold can be a serious problem under a buy-and-build plan, and the reverse is also true. There is no such thing as “good technology” in the abstract. There is only technology that fits or fails the thesis you are underwriting.
This is the same discipline that separates value creation consultants from operators with P&L accountability. An advisor produces the risk register. An operator tells you which two items on it will actually cost you EBITDA and when.
What to demand up front
- The written thesis and the growth math it depends on.
- The specific technical capability the thesis assumes exists.
- The point in the hold when that capability gets stress-tested.
2. Ownership, Licensing, and Who Actually Controls the Code
This is the item that has killed more deals in my experience than any performance problem, and it rarely shows up in a stack diagram. Who owns the intellectual property. Whether critical code was written by contractors under agreements that never assigned rights. Whether open-source components carry copyleft licenses that contaminate proprietary code the company believes it owns. Whether a founder-era handshake gave a third party perpetual access.
The SEC has been explicit that material technology and cybersecurity risks belong in disclosure, and the SEC’s tightening posture on both means a sloppy IP or security position is not just an engineering footnote, it is a value and liability question for the buyer.
You are buying the right to control and monetize an asset. If the ownership is cloudy, the asset is worth less than the model says, and sometimes it is worth nothing you can defend. This maps directly onto the kind of commercial due diligence red flags that look cosmetic in a data room and turn structural at close.
Checklist
- Full IP assignment chain for all core code, including former contractors.
- Open-source license inventory with copyleft exposure flagged.
- Third-party dependencies with contractual or perpetual-access terms.
- Domain, credential, and infrastructure ownership held by the company, not an individual.
3. Security and Compliance as a Priced Liability, Not a Checkbox
Security in diligence should never be a yes/no. It should be a number with a date on it. The question is not “do they have security,” it is “what will it cost, and how fast, to bring this to the standard the thesis requires, and what is our exposure if a breach happens between signing and remediation.”
A B2B business selling into regulated buyers with no SOC 2, no defensible data-handling posture, and no incident history is carrying a liability that either caps its addressable market or forces a spend you should be pricing into the deal now. Bain’s annual PE report, which you can follow through the Bain Global Private Equity Report, has repeatedly documented how operational and value-creation levers now carry the returns that leverage and multiple expansion used to. Security remediation is one of those levers when it unlocks a market segment the company cannot currently sell into.
Classify each finding
- Risk avoided: gaps that must be closed to prevent a loss, priced as remediation cost plus breach exposure.
- Enabled value: certifications and controls that open a buyer segment the company cannot reach today.
- Forecast: the revenue that segment represents, kept clearly separate from anything realized.
4. Architecture Judged Against the Growth Plan, Not Against Fashion
Engineers love to grade architecture on how modern it is. Buyers should grade it on one axis only: will it hold at the scale and shape the thesis requires, and what does it cost to get it there. A monolith serving a stable customer base at healthy margins is not a problem. A monolith that cannot be extended to support the three add-on acquisitions in the plan is a very expensive problem, and the two look identical in a stack diagram.
What I look for is the relationship between growth and cost. If revenue doubles, does infrastructure and engineering cost double with it, or does the architecture let margin expand as volume grows. That single question decides whether the technology is an EBITDA asset or an EBITDA drag over the hold.
The scaling questions that matter
- What breaks first under 2x, 5x, 10x load, and what does fixing it cost.
- Does cost scale linearly with revenue, or does the architecture allow operating leverage.
- Can the platform absorb an acquired company’s data and users, or does each add-on require a rebuild.
- How much of the codebase is understood by more than one living person.
That last point matters more than any framework choice. Concentration of knowledge is a risk that does not appear on a balance sheet and shows up the day a key engineer resigns.
5. The Team and the Bus Factor
You are not just buying code. You are buying the people who can change it, and the systems that let new people become productive. I have seen technically clean platforms become worthless because the only two people who understood them left within a quarter of close, and I have seen mediocre platforms thrive because the team could ship reliably and onboard quickly.
Assess key-person dependency directly. How many people could keep this system running and evolving if the top two engineers walked out. Look at documentation not as a nicety but as an insurance policy against exactly that. Look at whether the team can execute the roadmap the thesis requires or whether you are underwriting a hiring plan you have not budgeted.
This is where diligence and the first hundred days connect. The findings here should flow straight into the 100-day plan for a newly acquired B2B business, because a key-person risk you identify in diligence is a retention and documentation task you own on day one.
6. Data Quality and Management Visibility
Here is a test I run early. Ask the company for three commercial numbers, pipeline by stage, net revenue retention, and revenue by customer cohort, and watch how they produce them. If the answer comes from a clean system in an hour, the data infrastructure supports management. If it comes from a spreadsheet someone maintains by hand and cannot reconcile, you have found a visibility problem that will haunt every operating review you run.
PE buyers underestimate how much of value creation depends on being able to see the business clearly.McKinsey’s research on private capital, has consistently pointed to management information and performance transparency as differentiators in how the strongest funds run their portfolios. If the data cannot be trusted, forecasts cannot be trusted, and every plan you build on top of them inherits that weakness.
This is directly linked to how you will later run portfolio operating reviews around the commercial KPIs that matter. If the systems cannot produce those KPIs cleanly, the first quarters post-close get spent building plumbing instead of driving performance.
What to test
- Can core commercial metrics be produced on demand and reconciled to the financials.
- Is there a single source of truth, or reconciliation between competing ones.
- Does the data support the cohort and retention analysis your thesis depends on.
7. Technical Debt Translated Into a P&L Line
Technical debt is the most abused phrase in diligence. Engineers use it to mean “code I would have written differently.” Buyers should only care about the debt that has a financial consequence: work the business must do just to stand still, capacity consumed by maintenance instead of new value, and the accumulating cost of a decision deferred.
The way I translate it is to separate debt into two buckets. The first is debt that costs you nothing unless the thesis forces the issue. The second is debt that is actively draining engineering capacity every month, which is a real and recurring cost that belongs in your model. That second bucket often hides inside the numbers as normalized run-rate spend, which is exactly the kind of adjustment worth scrutinizing when you look at adjusted EBITDA and the art of add-backs.
The output I want is not a list of debt items. It is an answer to: how much of current engineering spend is buying new capability, and how much is just keeping the lights on. If eighty percent of the team’s time services debt, you are not buying a growth engine, you are buying a maintenance operation with a growth story attached.
8. Third-Party Dependencies and Concentration Risk
Every modern platform runs on other people’s software. That is fine until you find that the entire business depends on a single vendor’s API with no fallback, a payment processor that can change terms unilaterally, or a critical service running on a plan the vendor is sunsetting. Concentration risk in the technology estate is the mirror image of customer concentration risk, and it deserves the same scrutiny.
PitchBook and S&P Global both track how operational fragility surfaces in mid-market deals, and you can follow their coverage through PitchBook and S&P Global Market Intelligence. The pattern is consistent: the dependencies nobody mapped are the ones that generate surprises after close.
Map the critical dependencies
- Single points of failure with no contractual protection.
- Vendors whose pricing or terms could materially move the cost line.
- Services on deprecated tiers or approaching end of life.
- Anything that ties directly into the revenue path, where an outage is lost revenue, not just downtime.
9. Integration Readiness for the Buy-and-Build Case
If the thesis is a roll-up, integration capacity is not one item on the checklist, it is the checklist. The question stops being “is this platform good” and becomes “can this platform become the spine that absorbs the next five acquisitions, and what does each integration cost in time and money.”
I have watched buy-and-build theses stall because the platform company’s technology could not ingest an acquired company’s customers, billing, or data without a project that ate a full year and a budget nobody underwrote. The Harvard Law School Forum on Corporate Governance has published extensively on why integration execution, not deal sourcing, is where most value in acquisitive strategies is won or lost.
Judge integration readiness on whether data models are consistent enough to merge, whether the architecture is modular enough to onboard without a rebuild, and whether the team has done this before or is learning on your money. Get this wrong and every add-on in the model carries a hidden integration tax the thesis never accounted for.
10. Turning the Checklist Into a Deal Position
A technical diligence report earns its keep only when it changes what you do. Every finding should resolve into one of four positions, and I make the vendor or internal team state which one applies to each item.
The four positions
- Priced in: a cost we add to the model and remediate post-close, on a known timeline.
- Renegotiate: a finding material enough to move price or deal structure.
- Condition: something the seller must fix or warrant before we sign.
- Walk: a defect that breaks the thesis and cannot be remediated within the hold economics.
Most findings land in “priced in,” and that is exactly the point. A clean technical position that costs two million to bring to standard is not a reason to walk, it is two million you subtract from what you were willing to pay. The report that never gets to a number never earns a seat in the deal conversation.
This is also why I argue that value creation needs embedded partners rather than advisory firms. The team that finds the technical risk should be able to own the fix, because a finding without an owner and a plan is just a well-formatted worry. The same logic runs through how PE go-to-market efforts avoid value creation pitfalls: diligence that does not connect to execution is theater.
11. What This Buys the Deal Team
Run diligence this way and the deal partner gets a defensible view of whether the technology supports the thesis, the CFO gets remediation costs that belong in the model with dates attached, and the operating partner gets a head start on the first hundred days because the risks are already scoped as work.
The takeaways I would hold onto:
- Grade the stack against the thesis, never against what is fashionable. Fit is the only standard that matters.
- Ownership and IP problems kill more deals than performance problems. Verify the chain of control before anything else.
- Every finding becomes a number with a date, or it does not belong in the report.
- Data visibility is a value-creation prerequisite, not an engineering nicety. If you cannot see the business, you cannot improve it.
- Separate the debt that costs you nothing from the debt draining capacity every month, and only model the second.
- Resolve every item to priced in, renegotiate, condition, or walk.
If your thesis depends on the business scaling, integrating, or expanding margin, the technical checklist is not a compliance exercise. It is one of the clearest early reads you get on whether the number in your model is real. Treat it that way and it protects both your entry price and your exit. Treat it as a formality and you inherit every surprise you declined to price. The connection between clean diligence and a clean exit runs straight through the same discipline I describe in the B2B portfolio revenue leakage diagnostic and in the broader work of future-proofing organizations for the years ahead.
Where to Take This Next
If you are evaluating a target now, or inheriting a platform you already own and want a clear-eyed read on whether it supports the plan, that is the work my team does. We run technical diligence that resolves to money and dates, and then we stay to fix what we find. That is the difference between a report and a result.
To talk through a specific deal or portfolio company, start with a value creation advisory conversation, or review the full scope of engineering and diligence work at the DevriX private equity practice. Fractional operating support, from diligence through the first hundred days, follows the same principle I hold for a fractional CRO in PE: own the number, not the advice.
