Technical Due Diligence Language

Technical due diligence (TDD) is a structured assessment of a target company's technology assets, architecture, codebase, and engineering team carried out before an acquisition or investment closes. The goal is to identify risks, quantify remediation costs, and produce a report that informs deal negotiations.

Reviewers quantify tech debt using metrics such as the tech debt ratio (remediation effort divided by total development cost), code hotspot density, test coverage gaps, and the count of unpatched CVEs. The output is typically a debt register with a prioritised remediation roadmap and associated cost estimates.

RAG (Red, Amber, Green) scoring is a traffic-light rating system used to communicate risk severity at a glance. Red indicates a critical blocker or deal risk, Amber flags a significant concern that requires a remediation plan, and Green signals the area is satisfactory. Reviewers apply RAG ratings at both the dimension and summary levels.

Common terms include "single point of failure", "tightly coupled monolith", "insufficient horizontal scalability", "runaway infrastructure cost", and "architectural runway". Reviewers may note whether the architecture can support the acquirer's projected user growth without a costly re-platforming effort.

Vendor lock-in risk is assessed by mapping proprietary dependencies, evaluating migration cost estimates, and noting whether adapter or abstraction patterns are in place. Reviewers use phrases like "deep coupling to a single cloud provider", "no abstraction layer over the messaging platform", and "estimated migration effort of X person-months".

Key-person risk describes the danger of critical knowledge being concentrated in one or a handful of individuals who could leave the organisation. In a TDD report, reviewers flag this with language such as "the platform's core module has a single author with no documented succession plan" and recommend knowledge transfer or retention incentive clauses.

Typical executive summary language includes "the technology stack is broadly fit for purpose", "material risks were identified in the areas of scalability and security posture", "we recommend a price adjustment to cover remediation costs estimated at £X", and "subject to the conditions set out below, we recommend proceeding with the transaction".

Code quality is assessed through static analysis tools that measure cyclomatic complexity, duplication rates, and coupling. Reviewers report findings as "the codebase contains a high density of code hotspots in the payment module" and "test coverage stands at 34%, well below the industry benchmark of 70%".

In an acquisition, a portion of the purchase price may be held in escrow — a third-party account — pending the resolution of identified technical risks or warranties. The escrow amount is typically negotiated based on the estimated cost of remediating red-rated issues found during technical due diligence.

Technical due diligence reports are read by investors, lawyers, and executives who expect precise, professional language. Engineers who master TDD vocabulary can participate more effectively in reviews, draft clearer risk assessments, and communicate findings to non-technical stakeholders without losing accuracy or credibility.