What delivery data tells you before you buy a software company

You can learn a lot about a software company in a few weeks of diligence, and you can still be missing the thing that matters most once you own it: how hard is it for this team to keep changing the software?

That question comes up again and again among founders and engineers who've been through an acquisition. One founder described bracing for technical debt to drag down the valuation, then watching it barely register in the room. An engineer in another discussion put it more usefully: debt only becomes a business problem when each new feature starts costing more than the last one did. Both are circling the same idea. The state of the code at any single moment tells you less than how the code behaves when someone has to touch it.

That's what delivery data captures, and it's the part a code review can't reach.

Watch how the work moves, not how it looks

A code review is a photograph. It tells you what the software looks like on the day someone opened it up. Delivery history is closer to footage: it shows what happens every time the team has to change the thing.

How long does a change take to reach production? How long does finished code sit waiting for a reviewer? How often does a deploy need a second deploy to clean up after it? These sound like engineering housekeeping, but each one is a measure of the distance between "we've decided to do this" and "it's live for customers." That distance is what you're actually acquiring.

DORA has been studying this for more than a decade, and its current model tracks change lead time, deployment frequency, how quickly a team recovers from a failed deployment, change failure rate, and deployment rework. DORA frames these as indicators of whether a team can ship safely and efficiently.

The trap is fixating on any single figure. What's worth chasing is the shape of the data over time. A lead time that has been quietly climbing for a year is more interesting than a lead time that happens to look high this quarter. The company may still be hitting its roadmap. But if every change now takes more coordination and more rework than it did twelve months ago, you're looking at a system that's getting heavier to move.

Two caveats worth holding onto here. Small teams produce noisy data, and a single big migration or a founder's sabbatical can distort a chart without meaning anything about the underlying health. And plenty of good companies simply don't instrument this well enough to hand you clean numbers in a diligence window. The absence of data is its own signal, but it isn't automatically a bad one.

The waiting is often the story

If you only look in one place, look at the pull request.

A developer can finish a change in an afternoon and then wait days for anyone to review it. The review itself can bounce back and forth. Once it's approved, it can sit again before it ships. None of that waiting shows up in a demo, and none of it shows up in the code, but it's frequently where the real cost of change lives.

The scale of it is easy to underestimate. LinearB's 2026 benchmark, covering more than 8.1 million pull requests across over 4,800 teams, reports separate measures for stages such as coding and review pickup. For leaders, the useful question is where waiting time is increasing. A team’s overall cycle time may look stable even as changes spend longer waiting for someone to review them.

For a buyer, the point isn't whether the company clears somebody else's benchmark.

The useful question is whether the company's own data describes a stable process or a bottleneck that's been widening while everyone was busy shipping.

Speed and rework are not the same thing

A team can look fast simply because it ships often. That reading changes the moment you notice how much of the shipping is cleanup.

This is why DORA now tracks deployment rework as its own measure — the share of deployments that exist only because a previous one broke something in production. Ten deploys in a week is a very different story if three of them were unplanned fixes for the other seven.

Engineers tend to be skeptical of productivity numbers presented without this kind of context, and they're right to be. The recurring worry is Goodhart's law in practice: once a metric becomes the target, a team can move the number without improving anything underneath it. Deploy frequency is easy to game; a healthy deploy frequency alongside low rework is much harder to fake. So the thing to look for in diligence isn't one flattering figure. It's whether the figures agree with each other.

Delivery history shows you who the company actually depends on

Before an acquisition, investors need to understand whose knowledge the company relies on to keep its software running and evolving. A company might have ten engineers on paper while one or two hold the understanding needed to change its most critical systems safely.

Delivery and repository history help uncover that dependence. Who contributes to the critical components? Can other engineers maintain those areas without help? Concentrated activity is a reason to investigate further, especially when interviews reveal that essential knowledge has never been shared.

Avalia has encountered the consequences in practice. In a case described in its 2022 article on red flags in technology deals, software due diligence identified the risk of losing a key engineer. By the time she was approached after the deal closed, it was already too late. In 2026, that risk remains relevant: tools and development practices have evolved, but critical knowledge can still sit with people whose departure puts the post-acquisition plan at risk.

For an investor, that dependence can affect whether the company can deliver the post-acquisition plan. Identifying it before signing gives the buyer time to discuss retention and establish how critical knowledge will be transferred. It also provides a firmer basis for assessing the effort and risk involved in taking ownership of the software.

The question was never whether the team is fast

Traditional technical diligence spends its time on architecture, security, infrastructure, and code quality, and it should keep doing that. Delivery data answers a different and complementary question: what does it actually cost this company to use its technology on an ordinary Tuesday?

The two don't always agree. A clean codebase can sit inside a sluggish delivery system that makes every change a negotiation. A messier one can be handled fluently by a team that knows exactly where the bodies are buried. Neither is disqualifying on its own — but they're very different companies to own, and the demo won't tell you which one is in front of you.

You're not trying to find a flawless engineering organization; they don't come up for sale. You're trying to understand how easily this company can keep changing its product once it's yours, and how much of that ease walks out the door if the wrong person leaves.