What acquirers are really assessing in a technology review

Sellers prepare for a technology review as though it were an exam. Acquirers are not marking one.

An acquirer is pricing three specific things, and every finding matters only in so far as it moves one of them. Knowing which three changes what you prepare and what you argue about.

That framing is what a technical due diligence engagement is built around when the buyer is strategic rather than financial.

One: the cost to integrate

If the acquirer intends to merge the product into an existing platform, the question is how much work that is. Shared identity, shared billing, shared data model, one deployment pipeline rather than two.

What raises this cost: unusual technology choices that nobody on the acquiring side knows, tight coupling between the product and its infrastructure, and authentication built in-house.

What lowers it: boring technology, clear interfaces between subsystems, and the ability to run the thing in an unfamiliar environment. The clean-machine build from the checklist is really an integration-cost test.

Financial buyers weight this near zero. Strategic buyers frequently weight it above everything else, which is why the same company gets very different reports from two acquirers.

Two: the cost to keep it running

The standing engineering cost of the system existing, separate from building anything new. Patching, upgrades, incident response, the maintenance of integrations.

Acquirers estimate this from a small number of signals: how much of recent engineering time went to maintenance rather than features, how often incidents occur, how many people are needed to keep it up. A team where a large share of capacity goes to keeping the lights on is buying a liability with a revenue attached.

This is where technical debt actually gets priced. Not as an abstract quality judgement — as a number of engineer-months per year.

Three: how much value leaves with the people

The one sellers underestimate most.

If the system can only be safely changed by four specific people, the acquirer is buying those four people, and their retention terms become part of the deal rather than an afterthought. The bus-factor finding is not a code-quality observation; it is a valuation input.

The counter-evidence that carries weight: documentation that a newcomer used successfully, recent changes made by someone who joined in the last six months, and a deployment path that does not require a specific person.

What this changes if you are selling

Prepare the three things above rather than tidying the code.

Get a new starter to build and deploy the system from documentation, and record what they had to ask. That is a stronger artifact than any architecture diagram, and it directly addresses the third question.

Have the maintenance-versus-features split for the last four quarters ready with its method stated. If you do not measure it, the acquirer will estimate it, and their estimate will not be generous.

Sort out account ownership before the process starts. It is a small task that looks like disorganisation at exactly the wrong moment.

What this changes if you are buying

Say which of the three you care about before the review begins. A report written without that produces findings weighted for a different transaction than yours.

And be specific about integration intent. “We may integrate later” produces a report that hedges on the question that matters most.

Running it on yourself first

The version of this exercise with the best return is the one a company commissions on itself, twelve months before it expects to be reviewed.

The findings are the same. The difference is that there is still time to act on them, and acting on them is much cheaper than negotiating about them. Account ownership can be transferred. A licence problem can be replaced. A bus factor of one can be reduced by having someone else make the next round of changes to that subsystem.

What cannot be fixed in twelve months is the architecture, and that is worth knowing too — because then the work is framing rather than remediation, and framing is far more convincing when it is prepared rather than improvised in a data room.

The uncomfortable part is that a self-commissioned review is only useful if it is genuinely independent. A review that tells you what you want to hear has cost you money and bought you a false sense of readiness.

The limit on this

I am describing what technical reviews assess, not what determines whether a deal completes. Deals turn on commercial fit, on price, and on people, and a technology review is one input among several — usually not the decisive one.

I also cannot tell you what a specific finding is worth in price terms. That translation depends on the deal structure and on negotiating position, and it is made by the people running the transaction rather than by the reviewer.

Related reading: what technical DD means if the term is new, IT due diligence for the contract and licence side that often matters more in a transaction, and what a report contains for how findings are written so they survive a negotiation.