Technical due diligence

The difference between verified and reported.

An independent review for investors, acquirers and boards — where every finding says whether someone checked it or the company said so.

Book a technical call

You are about to take a risk on somebody else's technology, and the people who know most about it are the people with an interest in how it is described.

This sits inside technical advisory. The output is a short document: the findings that would change the decision, the ones that should become conditions, and an explicit statement of what was examined and what was not. Technical due diligence report — the short version describes that document and why the verified-or-reported convention is the part that matters.

What the engagement covers

Investor-side review before a round

Whether the technology supports the growth the plan assumes, and what the standing engineering cost of that growth looks like.

Acquirer-side review before a purchase

Three questions priced separately: what it costs to integrate, what it costs to keep running, and how much of the value leaves with the team.

Code and delivery review

Building the system on a clean machine from its own documentation, reading the tests rather than the coverage number, walking the deployment path, restoring a backup.

Licences, contracts and ownership

Dependency licences, customer commitments that transfer with the business, change-of-control clauses, and who legally controls the domains, cloud accounts and signing certificates.

Seller-side preparation

The same exercise run on yourself, twelve months early, while there is still time to act on findings rather than negotiate about them.

How it runs

Four stages in a fixed order: scope and question-setting, document review, hands-on verification, then interviews. Interviews come last on purpose — conducted first, they anchor the review to the team's account of their own system. The write-up on due diligence process covers the stages with the timings that hold when access is not the bottleneck, which it usually is.

The verification stage works through the write-up on due diligence checklist — items that test whether an artifact is true rather than whether it exists. Running alongside it is IT due diligence — the short version, covering licences, account ownership and contract terms, which in smaller transactions is frequently the half that produces the finding that changes the price.

If the term itself is new, tech dd — the short version is the plain explanation. If you are on the buy side of an acquisition, technology due diligence in mergers and acquisitions — the short version sets out the three things acquirers are actually pricing.

What you can inspect

The standard applied to a client's system is the one applied here. Egress policy agent runs a policy engine on a real capture and enforces 0 of 19 destinations, because two minutes is not a baseline. On the case studies page, an adversarial audit of my own fine-tuning pipeline surfaced 84 issues, including the reason the model recited instead of reasoned.

Both numbers are only worth something because the exercise was designed to find problems rather than to confirm the work.

What a review cannot tell you

It cannot tell you whether the architecture suits where the business is going, because that requires knowing where the business is going. It cannot detect a competent team that is demoralised, which is a genuine transaction risk that no artifact reveals. And it does not cover commercial, regulatory or people risk — a technical reviewer speculating about those is worth nothing.

Where access is limited, the report says so plainly rather than leaving an absence that reads like a clean bill of health. An unexamined system and a system found sound look identical in a report that omits its own boundaries.

topic map + semantic ranking

Continue with another article in this topic.

Bring the deal, not a brief.

Thirty minutes to scope what the review needs to answer, before anyone quotes it.