By Mario Peshev, DevriX
You have signed the LOI. Confirmatory diligence is running, close is six weeks out, and the seller has just granted your technical team read-only access to the repository. Someone on your deal team asks the question that will define the next month: “Is the code any good?” That is the wrong question, and it will get you a report you cannot act on. The right question is narrower and far more useful. What in this codebase changes the price, the plan, or the risk of the deal you are about to sign? A software code review for M&A that cannot answer that in commercial terms is an expensive line item, not diligence.
I have watched deal teams treat code review as a pass or fail gate, a thumbs up before wiring funds. It is not that. It is one input into three decisions a deal partner or operating partner actually owns: what to pay, what to fix in the first 100 days, and what to put on the risk register with an owner and a number attached. This piece is about how to commission that review, what it should surface, and how to read it so it moves those three levers.
What a code review is really scoping when the target is an acquisition
A code review commissioned for engineering hygiene and a code review commissioned for a transaction are different exercises with different deliverables. The engineering version asks whether the code is clean, tested, and idiomatic. The transaction version asks whether the code will support the thesis at the price you are paying, and what it will cost to make it do so if it does not.
Bain’s annual private equity report has, for years, tracked how much of the return in modern deals now depends on operational improvement rather than multiple expansion or leverage. You can read the trend in Bain’s Global Private Equity Report. When the return case rests on operating the business better, the software that runs the business stops being a technical footnote and becomes a value-creation variable. That reframes the code review. You are not grading the engineers. You are pricing the gap between the platform you are buying and the platform the thesis assumes you are buying.
This is why a code review never stands alone. It sits inside a broader technology due diligence exercise, and I have written separately about what the wider M&A technology assessment needs to put in front of a deal partner. The code is the ground truth layer under all of it. Architecture claims, roadmap promises, and team capability assertions are all testable against what is actually in the repository.
The four findings that actually move a deal
Most code review reports drown a deal partner in findings that do not matter to the decision. Style violations, minor tech debt, and framework version lag rarely change what you pay or how fast you integrate. Four categories do. I insist that any review I commission separates these from the noise.
Key-person and knowledge concentration
The single most common finding that surprises buyers is that one or two engineers hold the entire mental model of the system. The code compiles, ships, and generates revenue, but nobody except the founding CTO understands why a critical module works. This is a retention and integration risk with a direct commercial consequence. If that person walks after close, your first 100 days gets spent reverse-engineering a black box instead of executing the plan. A review reads this from commit history, code ownership distribution, and documentation coverage, not from what management tells you in the data room.
Scalability ceilings against the growth case
If the thesis assumes you triple transaction volume in three years, the review has to ask whether the architecture can carry that load or whether it hits a rewrite wall at 2x. That is not a code cleanliness question, it is an architecture and scalability review question, and it directly prices the growth thesis. A ceiling you discover post-close becomes an unplanned capital expense that was never in the model.
Security and data exposure liabilities
Hardcoded credentials, unpatched dependencies with known exploits, and unencrypted personal data are not hygiene items. They are contingent liabilities. The SEC has continued to sharpen disclosure and cybersecurity expectations for public and pre-IPO issuers, and you can follow that at the U.S. Securities and Exchange Commission. If your exit path runs through a strategic or a public listing, a security posture that a strategic acquirer’s own diligence will flag is a discount you inherit today.
Build-versus-buy honesty and licensing exposure
What the company calls proprietary IP is sometimes a thin wrapper around open-source components under licenses that impose obligations. A review that catalogs dependencies and their license terms tells you whether the IP you are buying is actually differentiated and legally clean, or whether the moat is thinner than the pitch. I keep this to commercial and technical framing and leave the license interpretation to counsel, but the review surfaces what counsel needs to look at.
How to read a code review report without being an engineer
You do not need to read code to read a code review, but you do need to demand that it speaks your language. A deliverable that lists 340 findings by severity is telling you it does not know what decision it serves. The report I want in front of a deal partner does three things.
- It ranks findings by deal impact, not technical severity. A critical security bug in a module you plan to deprecate matters less than a moderate scalability constraint on the core revenue engine. The report should say which is which.
- It attaches a rough cost and time to each material finding. “Payment module needs re-architecting” is useless. “Payment module re-architecture, roughly two senior engineers for four to six months, blocks the volume ramp” is a number you can put in the model.
- It classifies each item as price, plan, or risk. Price items adjust what you offer. Plan items go into the 100-day roadmap with an owner. Risk items go on the register with a trigger and a mitigation. Every finding should route to one of the three.
This is also the test I apply when I judge a vendor before they start. I have written a longer piece on how to judge a technical due diligence firm before you sign the engagement, and the short version is this: if they cannot describe their deliverable in the language of price, plan, and risk during the sales conversation, they will not produce it after you pay. A firm that leads with tooling and line counts is selling activity. You are buying a decision.
When a code review actually matters, and when it is theater
Timing changes what the review is for. The same exercise serves a different purpose at each stage of a deal, and commissioning the wrong depth at the wrong stage wastes money and time.
Pre-LOI
Before you commit, you do not need a full audit. You need a fast read on whether there is a deal-killer hiding in the code: catastrophic security exposure, an architecture that cannot survive the growth case, or IP that is not what the pitch claims. This is a screening pass. It is cheap relative to the deal, and it tells you whether to proceed and roughly where the risks cluster before you spend real diligence dollars.
Confirmatory diligence
This is where the full code quality assessment for acquisition earns its keep. Under a signed LOI with repository access, the review moves from screening to pricing. Every material finding now needs a cost, a time, and a routing to price, plan, or risk. This is the version that changes what you pay and what your 100-day plan contains. It is one component of full buy-side technology due diligence, which also covers the team, the roadmap, the infrastructure, and the vendor dependencies.
The theater version
The review becomes theater when it is commissioned to check a box for the investment committee rather than to inform a decision. You can tell because nobody has defined what finding would change the deal. If the answer to “what would make you walk or repricing?” is “nothing, we are buying regardless,” you do not need a code review, you need a receipt. Do not confuse the two. The wider research on deal performance from firms like McKinsey, whose private capital research covers value creation extensively, keeps returning to the same point: diligence that does not feed the operating plan rarely improves the outcome.
What the code review tells you about the price, not just the risk
Deal teams reflexively treat technical findings as risk-register material. The more valuable use is repricing. When a review says the core platform needs a nine-month, two-engineer re-architecture before it can carry the growth case, that is not just a risk. It is capital and time the seller’s model did not account for and yours now must.
I classify what a review surfaces into what is real and quantified today versus what is a forecast or a risk that may never trigger. A retention risk on a key engineer is a risk you avoid or absorb. A scalability re-architecture is near-certain cost you can move into the model with a defensible number. Keeping these categories separate is what lets you negotiate credibly. You are not saying “the code is bad, pay less.” You are saying “the growth case requires this specific work, here is the cost and timeline, and it belongs in the price.” Sellers argue with vibes. They cannot argue with a costed workstream.
This same logic runs in reverse on the sell side. When we help a portfolio company get ready to exit, the goal is to close these exact gaps before a buyer’s diligence finds them and prices them down. I have covered that in detail in the piece on exit readiness and the tech gaps buyers price down. The findings a buyer uses to negotiate are the same findings a seller should have neutralized months earlier.
Turning findings into a 100-day plan someone owns
A code review that ends at the report is half a deliverable. The findings that route to “plan” have to become sequenced work with owners, dependencies, and a place in the integration timeline. This is where most technical diligence quietly fails. The report gets filed, the deal closes, and six months later the same issues surface because nobody converted findings into a plan someone was on the hook to deliver.
The distinction between advice and a plan someone will execute is one I care about, and I have written about the difference between an operational value creation consultant you can ignore versus a plan someone owns. For code findings specifically, the routing looks like this:
- Day 1 dependencies. Anything that blocks integration, migration, or continued operation goes first. Key-person retention agreements often live here.
- First-quarter fixes. Security exposures and licensing cleanup that carry contingent liability but do not block operations.
- Value-creation sequencing. Scalability work timed to the growth ramp, not done all at once. You do not re-architect for 3x volume in month two if the ramp is in year two.
Executing this requires technical leadership the portfolio company may not have in-house. That gap is exactly why a part-time CTO seat or a virtual CIO arrangement often follows a code review directly. The review tells you what to do. Someone still has to enforce the decision rules that get it done.
The report you should refuse to accept
Let me be blunt about deliverables, because this is where budget gets wasted. I have seen enough weak diligence reports to name the failure patterns. Illustrative of what I mean: a 60-page PDF that is 80% a tool-generated static analysis dump, with an executive summary that says “the codebase is generally well-maintained with some areas for improvement.” That report cost real money and informs zero decisions.
Refuse any code review deliverable that does not do the following:
- State plainly whether anything in the code should change your price or your decision to proceed, in the first two pages.
- Attach a rough cost and timeline to every material finding.
- Route every material finding to price, plan, or risk.
- Separate what is quantified and near-certain from what is a contingent risk.
- Speak in commercial consequence, not technical severity scores.
The distinction between a review that finds problems and one that scopes them commercially is the whole game. Harvard Business Review’s ongoing coverage of mergers and acquisitions keeps circling the same finding: deals fail more often on integration and execution than on the thesis being wrong. Code review is one of the earliest places you can see whether the integration will be hard, and it is far cheaper to learn it before close than after.
What a deal partner should walk away deciding
Strip everything else away and a software code review for M&A exists to inform three decisions. First, does anything here change what I pay, and by how much. Second, what goes into the 100-day plan, with an owner and a date. Third, what goes on the risk register, with a trigger and a mitigation. If your review answers those three, it was worth commissioning. If it hands you a severity-ranked bug list, you paid for a receipt.
I run this discipline because the alternative is expensive. A costed, routed, commercially framed review costs a fraction of a single mispriced deal or a single blown integration. It is the highest-leverage diligence dollar I know of, precisely because it changes the number before you sign it rather than explaining the number after you regret it. The wider data on entry multiples and holding periods, tracked across sources like PitchBook, only sharpens the point: when you pay more and hold longer, the cost of a technical surprise you could have priced compounds.
Where this fits and what to do next
A code review is one instrument inside a full diligence and value-creation approach. It connects upward to the broader technology and revenue audit that runs in the first two weeks of a deal, and it feeds directly into the operating plan your private equity operating partners will run after close. Commissioned well, it changes the price you pay, the plan you execute, and the risks you carry into the hold. Commissioned as theater, it changes nothing except your diligence budget.
If you have an LOI signed or a confirmatory window opening, the fastest way to get a costed, decision-ready read on the code is a scoped engagement built for the deal calendar. Our 5-Day Tech DD and Pre-LOI screening for private equity is built to hand you exactly the price, plan, and risk output described here, on a timeline that fits confirmatory diligence. Bring us the repository access and the thesis, and we will tell you what in the code should move the number before you sign it.
