What does technical due diligence check before an investment or an acquisition?

Technical due diligence is for investors and acquirers who need to know what they are buying, and for founders who want to see it before an investor does. It is not a code-style review. The question is narrower: is there anything in the technology that should change the price, the terms or the plan? This is the checklist as we run it, in one week.

How the week works

We read before we have an opinion: read-only access to the repository and its history, the cloud and CI accounts, the board and any architecture documents, plus conversations with the people who built the product. Most findings come from comparing what the team says with what the repository shows.

The checklist

Architecture and its fit to the roadmap

We map what runs where and how the parts talk, then hold it against the roadmap the investment is meant to pay for. The question is not whether the architecture is elegant, but whether the next stage of the plan can be built on it, or needs a rewrite nobody has costed.

The data model and migrations

Does the schema match the business it describes? Are migrations versioned in the repository and reproducible from an empty database, or applied by hand in production? Do backups exist, and has anyone restored one? We also note where personal data lives, because that is where the regulatory risk sits.

Security

Four areas. Authentication and authorisation: how users sign in, and whether access is enforced on the server or only hidden in the interface, including whether one customer can read another’s data. Secrets: whether keys and passwords are in the code or its history, who holds them, and whether they can be rotated. Dependencies: known vulnerabilities and packages several major versions behind. Exposure: what is reachable from the internet that should not be, such as admin panels, open storage buckets, databases and debug endpoints.

Tests and CI/CD

Are there tests for the parts that carry money and data? Do they run on every change? Can the team deploy, and roll back, without one particular person? A product that only one engineer knows how to release is a finding on its own.

Infrastructure, cost and single points of failure

What the product costs to run each month, and how that bill grows with users. Then the single points of failure: one server, one region, one personal account that owns the cloud, the domain or the app store listing.

The team and the bus factor

The commit history shows who wrote what, and the conversations show who can explain it. We look at how much critical knowledge sits with one person, whether employees or contractors did the work, and whether any of it is written down. In a young company a bus factor of one may be acceptable; the buyer should still know where it is.

Licences and third-party dependencies

Open-source licences that conflict with the business model, such as copyleft code inside a product that is sold or distributed, and third-party services the product cannot run without, with their terms and their pricing. Whether contractors assigned their work to the company is a legal question, but the repository shows whose work to ask about.

The 2026 question: what AI wrote, and who read it

How much of the code was generated by AI coding tools, and did anyone read it before it merged? We do not treat AI-written code as a defect in itself; read and reviewed, it can be as sound as any other. The risk is code that nobody on the team has read or can explain, because nobody can maintain, secure or extend what they do not understand.

We ask, then check the evidence: the pull request history and whether changes were reviewed and by whom, the tool configuration committed to the repository, and the patterns unread generated code tends to leave, such as the same logic written several ways, tests that assert nothing, and security rules present but switched off. We do not rely on detectors that claim to tell which lines a model wrote. The review history answers the question that matters: who read it.

What the report contains

A written report, in plain language, that someone without a technical background can act on.

• A summary for the decision-maker: what we found, and whether anything should change the deal.
• Findings ranked by risk: each with the evidence (the file, the commit, the setting), why it matters, and what fixing it involves.
• What to fix before close: the findings serious enough to be conditions, such as exposed secrets, no working backups, or customer data reachable by other customers.
• What to price in: real costs after close that are not reasons to walk away, such as a module that will need rebuilding for the roadmap, a hire to cover a bus factor of one, or infrastructure costs that grow faster than revenue.
• What is sound: a report that only lists problems misleads in the other direction.

Who it is for

The investor or the acquirer commissions and receives it. Where the deal allows, we suggest sharing the findings with the founders, who will fix them; a finding discussed early is easier to settle than one raised at the last call before close.

Founders preparing to raise can commission the same review on themselves. It is cheaper to find an exposed key or a missing backup before an investor does.

What it does not cover

Technical due diligence sits beside legal and financial diligence, not in place of them. It is not a penetration test or a formal compliance assessment; where one is needed, the report says which and why. And it does not grade taste: code we would have written differently is not a finding unless it costs the buyer something.