The Biggest Unpriced Risk in Software M&A
Why delivery performance should become part of technical due diligence.
We have become very good at evaluating technology
One of the most interesting things about acquisitions is how much attention we pay to understanding what a company has built.
We review the architecture, we assess the technology stack, we evaluate security, scalability and technical debt. Moreover, we meet the engineering leadership team and try to understand whether they can execute on the roadmap after the transaction closes.
Those conversations are important. They always will be.
But after spending years on every side of these transactions, first as a portfolio manager, later as a founder who has sold companies to Telefónica and Block, and as an investor and board member, I've come to believe that many acquisitions underestimate a different type of risk: Delivery risk.
When you acquire a software company the main value is not the software itself but the organization's ability to continue creating value. And those are not always the same thing.
And here is the uncomfortable part: that gap between the two is rarely priced. It doesn't show up as a line item in the model, it shows up later, as a missed roadmap, a wider escrow, or an earn-out that never pays out.
A product is only as valuable as the system that keeps improving it
Most successful software companies have products that reflect years of accumulated decisions:
The codebase tells part of the story.
The people tell another.
What is much harder to see is the operating system that sits underneath both: How work moves through the organization, how decisions are made, whether quality scales as the company grows, whether knowledge is concentrated in a handful of individuals or distributed across teams and whether delivery depends on repeatable systems or on a few exceptional people constantly solving problems.
Key-person concentration deserves special attention, because it is the risk data rooms are best at hiding. Every investor has seen the version of this story: the deal closes, two engineers leave in month four, and the roadmap leaves with them. What's changed is that this is now measurable. Bus factor, how much of the delivery system depends on a handful of individuals, can be read directly from how work actually flows through the organization. It is often the single largest unpriced liability in a software acquisition.
These characteristics rarely appear in a due diligence report. Yet they often determine whether the business continues to compound after the acquisition.
AI is making this harder to evaluate
The rise of AI has changed the economics of software development remarkably quickly.
Teams are shipping more code, individual engineers are becoming significantly more productive and autonomous agents are starting to participate in the delivery process alongside developers. We see this pattern consistently across the organizations we work with.
On the surface, that should make engineering organizations easier to scale. In reality, it often makes them harder to understand. AI is increasing output. It is not necessarily increasing performance and diligence has no standard way yet to tell the two apart.
Higher output hides growing complexity: A company may appear to be accelerating while quality slowly deteriorates and AI may genuinely improve execution in one part of the organization while creating entirely new bottlenecks somewhere else. More code shipped can also mean more code reworked, a quality tax that consumes part of the apparent productivity gain. In one organization we analyzed over a 90-day window, 39% of merged code was AI-assisted and the team was shipping 1.2× more output. Yet 45% of pull requests required rework, and the company was on track to spend an extra $350K on AI that year without a corresponding gain in actual delivery. Two engineering teams can produce similar amounts of software while operating with completely different levels of sustainability.
For an acquirer, those differences matter enormously: You are not buying today's velocity. You are underwriting tomorrow's ability to deliver. And increasingly, the velocity in the data room is AI-inflated velocity, activity that may or may not represent a durable improvement.
Delivery should become part of due diligence
I suspect technical due diligence will evolve considerably over the next few years.
Understanding the architecture will remain essential but understanding the operating model will become equally important.
Before signing, buyers will increasingly want answers to five questions:
How consistently does this team deliver and how do we know?
Where does work actually slow down inside the organization?
Are the AI productivity gains durable improvements, or temporary spikes in activity?
Is quality improving alongside speed, or quietly paying for it?
Does performance depend on systems that scale, or on individuals who might leave?
Those questions don’t need to be answered after an acquisition, they need to be answered earlier to influence the value of the acquisition itself.
There is a quality-of-earnings dimension to this as well. Software capitalization, meaning the portion of engineering work that can legitimately be capitalized, is still commonly based on timesheets and management estimates. Yet the arithmetic is unforgiving. Software deals routinely price at 15× EBITDA or more, and for a mid-sized company spending $8–10 million a year on engineering, a misclassification of just two or three percentage points in what gets capitalized moves EBITDA by $200,000 or more. At deal multiples, that is a seven-figure swing in enterprise value, resting on assumptions nobody can verify.
The same logic applies on the way out. Funds that under-diligence delivery when they buy tend to get price-chipped when they sell because at exit they cannot evidence the efficiency and AI gains of the hold. If the improvement was real, it should be provable. If it isn't provable, the buyer will price it as if it weren't real.
Today, those numbers can be derived directly from the work itself, traced back to the underlying pull requests and tickets, and independently validated. For anyone who has sat through a quality-of-earnings discussion over add-backs and capitalization policies, the difference between an estimated figure and an auditable one is often the difference between negotiation and fact.
The companies that create the most value are usually the most predictable
When I think about the best engineering organizations I've seen, what stands out isn't simply that they build great products. It's that they build them consistently.
Their leaders understand where delivery is accelerating and where it isn't, whether AI is creating durable improvements or temporary spikes in activity and they can explain how engineering translates into business outcomes because they understand the system behind the software.
That kind of predictability creates confidence, and confidence is one of the most valuable assets in any acquisition.
But let's be precise about the mechanism. Uncertainty in a deal never disappears, it always gets priced. It gets priced as a wider discount, a larger escrow, a lower multiple, or a more punitive earn-out structure. The only real question is whether you priced it, or the other side did.
Because in the end, buyers are not purchasing a snapshot of a product. They're investing in a machine that needs to keep creating value long after the deal is signed.
At Pensero, this is exactly the layer of evidence we are building: an objective read on delivery, quality, AI impact and key-person risk, drawn from the signals already in a company's tools. The platform has analyzed more than one million pull requests and tickets across 5,000+ engineers, which means every read comes with industry context, not just internal numbers. If you are underwriting a software asset this quarter or preparing one for exit we can run that read in days, not weeks.
About:
Bernardo Hernández is co-founder of Pensero. He co-founded idealista, was an early investor and board president at Tuenti (acquired by Telefónica), led Flickr at Yahoo and product at Google, and was CEO of Verse (acquired by Block). He began his career as a portfolio manager at Fidelity and Putnam Investments and holds the CFA designation.
