Two years ago, technical due diligence in a PE transaction was a settled process. The buyer's team worked through the architecture and the codebase, producing a report that broadly confirmed what had already been priced in. Some technical debt would surface, but rarely anything that changed the transaction fundamentally. The formal process is similar, but what has changed is the questions diligence teams are asking, and the findings that influence value once the report has been written.

AI is now being reviewed separately

‍

Increasingly, we’re seeing AI assessed as area during technical due diligence, rather than simply being considered as part of the wider technology review. Buyers are testing whether the AI in the business represents genuine capability or whether it has simply been positioned that way within the value creation narrative.

‍

A dashboard with a recommendation engine added on top of it looks like AI in a board update, but at the diligence stage it is quickly reclassified as an efficiency improvement to a process that already existed. Buyers pay a premium for capability that genuinely changes how the business operates, which is why portfolio companies that haven’t been thinking about their AI in these terms find the conversation moves much faster, and in a different direction, than they expected.

‍

The second thing buyers are testing is whether the AI depends on the platform underneath it or it is running on infrastructure that was never designed to support it. If the capability cannot be scaled or maintained once the current engineers move on, it gets treated as a maintenance liability rather than an asset. Two years ago, the same setup might have been acknowledged as technical debt and moved on. Increasingly, it’s becoming something buyers are pricing into the transaction.

Buyers are now looking at the engineering team

‍

The buyer's team now wants to know not only what the codebase does, butwho on the current team understands it well enough to keep it working after thedeal closes.

‍

When large parts of the codebase have been shipped faster than the team has been able to own them, the acquisition risk sits with the two or three engineers who understand the critical services. Buyers now spend diligence time working out who those engineers are and what happens to delivery velocity in the six months after the deal closes if they decide to leave. These were much easier to answer two years ago and now have the potential to move the offer.

‍

We’ve seen this play out first-hand with one of our clients ahead of an acquisition. Much of the AI adoption was driven by individual engineers experimenting with tools independently, rather than being governed as an organisational capability.

‍

We helped them put a governance and EU AI Act framework in place first, then introduced Claude Code across the engineering function, and evolved hiring practices so that AI-assisted development became an organisational capability rather than something a couple of engineers were doing in isolation.

‍

That's the shift buyers are pricing now. The question buyers are increasingly asking is whether that capability would still exist if the person who built it left the week after signing.

What preparation should look like

‍

If you are running an engineering function inside a PE-backed business, and particularly if the anticipated exit window is within the next eighteen months, there is value in stress-testing where the business would land against the newer diligence questions before anyone from the buyer's side starts asking them.

‍

The two things worth knowing before diligence starts are how a buyer would categorise the AI in the value creation plan, and which specific engineers on the current team could rebuild the most commercially critical services from scratch. The first tells you where the premium is at risk and second tells you where the acquisition risk sits.

‍

The businesses that come through diligence well started asking these questions before the transaction window opened, rather than in the quarter before it. That is typically where our work begins; helping technology leaders and operating partners understand how their platform and engineering capability would stand up to buyer scrutiny, and identifying the specific work needed before those questions are asked for real.