Tech DD: what the term means and what it involves

Tech DD is shorthand for technical due diligence. It usually arrives in a term sheet or an investor email with no explanation, on the assumption that everyone already knows.

This is the plain version: what it is, who wants it, how long it takes, and the things it is regularly confused with.

The engagement itself is described on the technical due diligence page; this is the vocabulary you need before that page is useful.

What it is

An independent examination of a company’s technology, commissioned by someone about to take a risk on it. The output is a written assessment of what the technology is, what condition it is in, and what it would cost to keep or integrate.

The key word is independent. The same review conducted by the team that built the system is a self-assessment, and it is not what a term sheet means by the phrase.

Who commissions it

Investors, before a round, usually at Series A and above. Their question is whether the technology can support the growth the plan assumes.

Acquirers, before a purchase. Their question is what it costs to integrate, what it costs to run, and how much of the value is in people who might leave.

Boards, occasionally, when something has gone wrong or a large commitment is being considered.

Companies about to be reviewed, on themselves. This is the least common and frequently the highest-value version: finding the issues before someone else does, while there is still time to fix or frame them.

How long it takes

Four to fifteen working days of actual work for most companies, and two to four weeks of elapsed time. The gap between those two numbers is access — repository permissions, a read-only production account, people available to be interviewed.

If you are being reviewed, granting access quickly is the single biggest thing you control. If you are commissioning one, agree access in the term sheet.

What it is not

Not a security audit. Related and not the same. A security audit tests whether the system can be attacked. Tech DD notes the security posture as one input among many and does not attempt a penetration test unless that is separately scoped.

Not a code quality review. Code quality is a means, not the finding. A review that produces a list of style complaints has misunderstood its purpose.

Not a compliance certification. It does not produce a certificate and it is not accepted as one. If a counterparty needs a specific standard, that is a separate exercise.

Not an audit in the accounting sense. No standard body governs it, there is no defined opinion format, and quality varies enormously between providers. That is worth knowing when comparing quotes.

What a good one produces

A short list of findings that would change a decision, each marked as verified or reported, each with an estimated cost or an explicit note that it could not be estimated.

Anything else — the long list of minor observations, the architecture diagram redrawn, the summary of what the company already told you — is padding. Useful reports are shorter than expected and uncomfortable to read.

If you are the one being reviewed

Do not tidy the code. It does not help and it introduces risk in the middle of a transaction.

Do make sure the system builds from documentation on a clean machine, get the account ownership straight, and know your maintenance-versus-features split. The reviewer will form a view on all three whether or not you prepare, and the version they form unaided is rarely the flattering one.

What it costs

Fees vary widely because the work is not standardised, and the useful comparison is not the headline number but what stage the quote covers.

A document-review-only exercise is a few days of work. A review that builds the system, restores a backup and verifies licences is substantially more, because it is substantially more work. Two quotes that differ by a factor of three are often quoting different exercises rather than different rates.

When comparing, ask two questions: which stages are included, and what proportion of findings will be marked verified rather than reported. The answers tell you what you are buying more reliably than a day rate does.

For the company being reviewed, there is a cost too, and it is rarely counted: engineering time spent answering questions and assembling artifacts. Budget a few days of a senior person’s attention, and more if the documentation is thin.

The honest caveat

Because nothing standardises this work, “we had tech DD done” tells you very little on its own. Ask what stages were actually completed and what was verified rather than reported. A review that stopped at document review is a legitimate commercial choice and a very different artifact from one that built the system and restored a backup.

Related reading: what acquirers actually assess, IT due diligence for the contract and licence side, and what a report contains for the deliverable itself.