Technical Due Diligence Checklist: Technology and AI

Start with the decision, not the codebase

Good diligence is scoped by the decision it informs. An investor needs to know whether the technology can support the growth plan and what it will cost; an acquirer also needs to know how hard integration will be; a company choosing a vendor needs to know what it would take to leave. Agree those questions first, then decide how deep each area needs to go.

Many of the architecture questions overlap with a modernisation decision, covered in Modernise or Replace? A Decision Framework for Ageing Platforms. Diligence asks them under time pressure and with a transaction attached.

Architecture and code

Architecture. Does the structure fit the business model and the plan for the next two to three years? Where are the boundaries, and how coupled are the parts that will need to change most?

Codebase health. Sample the code rather than reading all of it. Look at test coverage in critical paths, how changes are reviewed, how old the core dependencies are and how much of the system only one or two people understand.

Technical debt. Separate debt that is an engineering inconvenience from debt that limits the plan: debt that blocks scaling, security or a key integration is material; untidy code in a stable area usually is not.

Infrastructure, security and operations

Infrastructure and cost. Understand where the system runs, how cost scales with usage and whether the bill is understood by anyone who could change it.

Security posture. Review access control, secrets handling, dependency management and incident history. A penetration test is a separate specialist exercise; diligence should say whether one is needed and what it should cover.

Reliability. Look at monitoring, incident response, backups and recovery. The question is whether the team would know about a serious problem before customers did.

Team, process and delivery

Interview the technical leadership and key engineers. The aim is to test depth and understanding, not to catch people out: can they explain the architecture, the trade-offs already made and the risks they worry about?

Examine how work moves from idea to production, how predictable delivery is, and what happens if one or two key people leave. Key-person dependency is one of the most common material findings in smaller companies.

Where the target relies on an external development partner, the questions in How to Choose a Development Partner Without Handing Over Your Product apply directly: who owns the code, the accounts and the knowledge.

Data, dependencies and intellectual property

Check that the company has the rights to the data its product and its AI depend on, and that personal data is handled in line with the obligations of the markets it serves.

List third-party components and their licences, and note any that could restrict how the product is sold or modified. Confirm that the code and other intellectual property belong to the company, including work done by contractors and partners.

When the platform itself is the constraint, a technology architecture review separates the risks that matter commercially from those that do not.

AI claims

Separate demonstration from description: ask to see what the AI does in the product today, on realistic inputs. Establish which parts are proprietary and which depend on third-party models or APIs, with what contractual and cost exposure, and how quality is measured when the model is wrong. The full set of questions is in How to Test an AI Vendor’s Claims Before You Sign or Invest.

Roadmap feasibility and the report

Finally, test the roadmap against everything above. Can the current team, architecture and budget deliver it, and what investment would close the gap?

The output should be an executive risk summary for the people making the decision, with findings rated by materiality, the evidence behind each, and a clear statement of what could not be verified. Where the decision is material, independent technical due diligence gives investors, acquirers and boards that view without an interest in the outcome.

Related: AI in Web Development: The Bottleneck Has Moved and How to Test an AI Vendor’s Claims Before You Sign or Invest.