The diligence process, stage by stage, with real timings

The technical part of a transaction runs in four stages, and they are not interchangeable. Each one can only produce certain kinds of finding, which means the stage you are in determines how much weight a finding should carry.

The other thing worth knowing up front: the schedule is set by how fast access is granted, not by how long the analysis takes. Nearly every delay I have seen was a permissions problem wearing an analysis costume.

What follows is the sequence used in a technical due diligence engagement, with the timings that hold when access is not the bottleneck.

Stage one: scope and question-setting

Half a day to two days. Before anything is examined, the questions get written down: what would change the price, what would stop the deal, what is merely interesting.

Skipping this is the most common failure. Without it, diligence becomes a general survey, and a general survey of any codebase produces a long list of things that could be better, none of which is decision-relevant. A finding matters only relative to a question somebody actually had.

Stage two: document and artifact review

Two to four days, and it can start before access to the code is granted, which makes it a good use of the waiting period.

Architecture documents, licence inventories, incident history, org structure, contracts with technical obligations in them. This stage produces claims rather than facts, and its real output is a list of things to verify later.

The signal here is not the quality of the documents. It is the distance between what they describe and what the next stage finds.

Stage three: hands-on verification

Three to ten days, and this is where the answer actually comes from.

Building the system from source. Reading the tests. Walking the deployment path. Restoring a backup. Checking the licences that were claimed. This is the stage that distinguishes verified from claimed, and it is the stage most often compressed when a deal is moving fast.

Compressing it is a decision with a consequence, not an efficiency. A review that only reaches stage two produces a report full of the word “reportedly,” and that word is doing a lot of work.

Stage four: interviews

One to three days, and deliberately last.

Interviews conducted before verification produce a narrative that is hard to dislodge. Conducted after, they explain findings you already have — which is enormously more useful, and considerably more comfortable for everyone, because the questions are specific rather than fishing.

The most valuable question at this stage is what the team would fix first given three months and no feature pressure. The answer is usually accurate and it is rarely in any document.

What sets the real timeline

Access. Repository permissions, a read-only production account, the licence inventory, someone available to answer questions.

Two weeks of elapsed time routinely contains four days of work and ten days of waiting. If you are running the buy side, the highest-leverage thing you can do is get access agreed in the term sheet rather than negotiated afterwards.

The compression that is legitimate

Where the transaction is small or the technology is not the value, running to stage two and stopping is a reasonable commercial decision — provided the report says that is what happened.

The failure is not stopping early. It is stopping early and presenting the result as though stage three occurred. That is how a review that found nothing gets read as a review that confirmed nothing was wrong, and those are very different statements.

Where the sequence breaks

Two failures account for most of the bad reviews I have seen.

Interviews first. Someone schedules the team conversations early because calendars are hard, and the review is then anchored to the team’s account of their own system. Verification afterwards tends to confirm rather than test, because the reviewer already has a story and is looking for support.

Scope set after the findings arrive. Without stage one, the questions get written retrospectively around whatever turned up. That produces a report which answers questions nobody asked and misses the one that would have changed the price.

Both are scheduling accidents rather than analytical ones, which is why they are so common and so avoidable. The order is the method.

What I cannot promise here

I cannot promise a fixed timeline without knowing the access situation, and any firm quoting one has either seen your data room or is quoting the work rather than the elapsed time. Ask which.

I also cannot cover every category of risk in these stages. Commercial, regulatory and people risk sit outside a technical review, and a technical reviewer speculating about them is worth exactly nothing.

Related reading: the checklist is what stage three actually works through, IT due diligence covers the infrastructure side that runs in parallel, and what a report contains covers how these stages turn into a document somebody can act on.