Technical due diligence checklist

I have sat on both sides of the technical due diligence table. For seven years I was CTO of iamproperty, answering the questions. Now, at Stable State, I am usually the one asking them, either for an investor or for a management team getting ready to sell. The same handful of issues come up again and again, so alongside the checklist I have included a few anonymised stories from that work.

How to use this checklist

Technical due diligence is not an exam with a fixed syllabus. Every buyer arrives with its own request list, shaped by the deal, the sector and what worries its investment committee. Underneath that variety, though, the same six questions come up again and again, and this article follows them, using the six areas of the Stable State Technology Readiness Framework.

For each area, the question I ask management teams is not "what will they ask?" but "could we answer it convincingly this afternoon?" Treat "have ready" literally. If producing a document would take a fortnight of engineering time in the middle of a live deal, it is not ready, and the scramble to produce it will be visible to the buyer. Use what follows as a baseline rather than a guarantee of coverage.

1. Strategy

Investors start by asking whether the technology is pointed in the same direction as the business. They want to understand how technology spend and priorities relate to the business plan, and whether the technology roadmap can support the growth the investment case assumes. A plan that promises new markets or products, sitting on a roadmap that says nothing about either, is the kind of disconnect a buyer notices quickly.

They will also look back at the significant decisions that shaped the platform: what was built, what was bought, what was outsourced and why. Increasingly they ask about AI too, and the test is whether the plans are credible, resourced and connected to commercial outcomes rather than included because the board expected to see them.

Management should be able to show a technology strategy or roadmap that visibly connects to the business plan, the technology budget and headcount with actuals and forecast, and a short record of the major decisions of the last two or three years and the reasoning behind them. That record matters more than it sounds. It shows a buyer that decisions were made deliberately, not inherited by accident.

2. Product

The product review is where the revenue forecast meets reality. A buyer wants to know whether the roadmap can deliver what the forecast depends on, and the most persuasive evidence is not the roadmap itself but how well previous roadmaps were delivered. A team that has consistently shipped what it planned earns belief in its next plan.

Investors also want to understand how product decisions are made and by whom, how well the business understands the way customers actually use the product, and how much of the product is genuinely shared. Customer-specific features, forks and bespoke deployments are common in growing businesses, and they are not fatal, but they change the economics of the platform and buyers will want to see them clearly.

Have the current roadmap ready alongside a candid record of what was delivered against previous ones, a list of customer-specific work, and whatever product and usage analytics the business already relies on.

3. Team

A buyer is not only acquiring a platform. It is acquiring the people who keep that platform running and move it forward, often at the moment those people are considering their own futures. The team review therefore looks at structure, capability and capacity against what the plan will ask of them, at attrition and hiring, and at whether there is a credible layer of leadership beneath the CTO.

The issue that attracts most attention is key person dependency: knowledge, access or responsibility concentrated in one or two individuals. Close behind it is the use of contractors and agencies, and in particular which systems they own and whether anyone in-house understands them.

Management should have an organisation chart showing roles, tenure and employment type, a list of contractors and agencies with the components each is responsible for, and an honest view of who holds critical knowledge and access, together with what is being done about it. We cover this in more depth in key person dependency in technical due diligence.

4. Approach

The engineering approach tells a buyer whether the roadmap can be trusted. Investors look at how work moves from an idea into production, how testing and code review work, how often and how safely the team releases, and how incidents are handled when things go wrong. What they are really assessing is predictability. A team that delivers steadily and recovers well from problems is one whose plans are worth believing.

The evidence here should describe the delivery process as it actually runs, not as the wiki says it should. That means the build and deployment pipeline and the approach to automated testing, the incident log with any post-incident reviews, and a release history over a meaningful period. A year of real data is far more persuasive than a well-written process document that nobody follows.

5. Platform

This is the part of due diligence most people picture: the architecture, the code and the technical debt. A buyer wants to know whether the platform can handle the volumes the plan assumes, what it costs to run and how that cost grows with revenue, and which third-party services and dependencies would be hard to replace.

The aim is not a perfect codebase, which no growing business has. It is a platform the team understands and can describe consistently. Current architecture diagrams that the engineers agree are accurate, hosting and infrastructure costs with the trend over time, a list of critical dependencies and any evidence of performance under load all help.

So does a technical debt register that records each significant item with its impact and an estimate of the effort to resolve it. Debt that management has identified and sized is a very different conversation from debt a buyer finds for itself, as we explain in technical debt and company valuation.

6. Security, data and IP

The final area covers the liabilities a buyer would inherit. Investors look at access control, vulnerability management and incident history, at what personal data the business holds, where it lives and how it is protected, and at the risk carried by suppliers and third parties. They also check that the business actually owns what it is selling: the code, the IP and the right to use the open-source components inside the product.

The common weakness here is security that exists on paper but not in practice. Policies matter far less than evidence that they are followed, such as regular access reviews and recent penetration tests with the findings tracked to resolution. Alongside that, have records of data processing, any certifications the business holds such as Cyber Essentials or ISO 27001, an inventory of open-source components and their licences, and contracts confirming that the business owns code written by contractors and agencies. IP gaps in particular are far easier to close before a deal than during one.

Gaps that slow a process down

In my experience, it is rarely an individual technical issue that makes due diligence painful. The process slows down when evidence exists only in people's heads, so every answer has to be reconstructed and the same few people become a bottleneck. It slows further when management and the technical team give different answers to the same question, because inconsistency makes a buyer look harder at everything else.

And it suffers when documents are produced for the deal. Buyers can tell the difference between documentation the team genuinely uses and documentation written last week, and the second kind undermines confidence rather than building it.

When to start

Ideally 12 to 24 months before a transaction. That leaves time to fix what matters, not just to document it. The businesses I have seen come through due diligence most smoothly were not the ones with the best technology. They were the ones that had already asked themselves the hard questions.

The Technology Exit Readiness guide explains why the timing matters, and a ClearView assessment shows where you stand against all six areas in two weeks.

If you are on the other side of the table, see how Stable State approaches technical due diligence for investors.