Technical Due Diligence

A structured review of an organisation's or product's technology stack, architecture, codebase, team capabilities, and security posture — conducted by an acquirer, investor, or board before a major transaction or strategic decision.

"The PE firm commissioned a 3-week technical due diligence engagement before the acquisition. We reviewed 140,000 lines of code, the infrastructure architecture, 4 years of incident history, and interviewed the 8-person engineering team."

A structured assessment matrix rating key architecture dimensions — scalability, resilience, security, maintainability, testability, observability — on a defined scale. Provides a comparable snapshot of architectural health.

"The architecture scorecard gave the system a 3/5 on resilience (single-AZ deployment, no tested DR) and 2/5 on observability (no distributed tracing, log coverage at 40%). Both are on the remediation roadmap."

A systematic analysis quantifying the accumulated technical debt in a codebase — the cost of rework required to bring quality to an acceptable level. Usually expressed as estimated engineering weeks and categorised by type (design debt, code debt, test debt).

"The tech debt assessment found 48 weeks of remediation work: 20 weeks of missing test coverage, 15 weeks of API refactoring (REST → async events), and 13 weeks of infrastructure-as-code migration from manual provisioning."

A metric expressing tech debt as a percentage of the total estimated cost to build the system from scratch. A ratio above 20% is typically a concern; above 40% may indicate the system is approaching a rewrite decision.

"SonarQube calculated a tech debt ratio of 31% — the total estimated remediation effort is 31% of the estimated original build cost. This is in the 'high concern' range and will be highlighted in the DD report."

Identifying the files or modules in a codebase with the highest combination of complexity and change frequency. Hotspots are where bugs are most likely and where the cost of change is highest — top candidates for refactoring.

"CodeScene hotspot analysis flagged the PaymentProcessor class — 1,400 lines, cyclomatic complexity 87, modified 340 times in the past year. This single file accounted for 60% of production bugs in the same period."

The risk that the current architecture or codebase cannot handle projected growth in users, data volume, or transaction rate without significant rework. Assessed by identifying architectural bottlenecks and the effort to remove them.

"Scalability risk: the monolithic session store becomes a bottleneck above 500 concurrent users. The current user base is 12,000; projected growth to 80,000 in 18 months. This is a critical risk requiring architectural remediation within 6 months."

A component whose failure causes the entire system to fail. A key finding in technical due diligence — the presence of SPOFs without mitigation is a significant reliability and business continuity risk.

"We identified 4 SPOFs: a single Postgres instance with no replica, a third-party payment gateway with no fallback, all deployments running through a single Jenkins instance, and a single DNS provider with no secondary."

A summary of quantitative code quality metrics — test coverage, code duplication, cyclomatic complexity, static analysis violation counts, dependency vulnerability scan results — used to communicate technical risk to non-technical stakeholders.

"The code health report is a 2-page executive summary: test coverage 34% (benchmark: 80%), 420 high-severity static analysis violations, 12 critical CVEs in dependencies unpatched for 180+ days. 'Red' overall."

The risk that deep dependency on a proprietary vendor technology makes switching vendors prohibitively expensive or complex. Assessed by mapping proprietary API usage and the estimated migration cost.

"Vendor lock-in risk assessment: 80% of the data pipeline uses AWS Kinesis Data Firehose with transformation logic in Lambda — migrating to a cloud-agnostic stack is estimated at 22 engineering weeks. This is flagged as a medium risk."

A dependency on a vendor-specific API, service, or file format that cannot be easily replaced with an open standard equivalent. A key contributor to vendor lock-in risk.

"The application has 14 proprietary dependencies on Azure Cognitive Services APIs — there is no drop-in open-source equivalent for 6 of them. This is a significant lock-in risk that doubles the multi-cloud migration cost estimate."

A quantified projection of the engineering effort, infrastructure cost, and operational disruption required to move from the current technology state to the target state. A key deliverable in tech DD for M&A transactions.

"The migration cost estimate for moving from the custom ORM to the standard data layer: 14 engineer-weeks of code changes, 3 weeks of regression testing, 2 weeks of phased rollout. Total: $180K at current team cost rates."

A concise, non-technical summary of technical due diligence findings, calibrated for C-suite or board audience. Translates technical risk exposure into business impact, cost, and timeline terms.

"The executive summary leads with: 'The platform can support the projected 5x user growth, but requires $400K of infrastructure investment in the next 9 months. The security posture has 3 critical findings that must be remediated before any public launch.'"

A structured log of identified risks, their likelihood, impact, owner, mitigation plan, and current status. In technical due diligence, the risk register is the core artefact that drives remediation planning and investment prioritisation.

"The tech DD risk register contains 28 items: 3 Critical (SPOF, unpatched CVEs, no BCDR), 9 High, 12 Medium, 4 Low. Each entry has an owner, a mitigation timeline, and a remediation cost estimate."

Red/Amber/Green status classification used to communicate risk levels in reports and dashboards. Red = critical risk requiring immediate action; Amber = significant risk requiring a mitigation plan; Green = acceptable, no immediate action required.

"Architecture dimensions RAG summary: Security: Red (3 critical unpatched CVEs, no WAF). Scalability: Amber (meets current load, bottleneck at 3x growth). Resilience: Amber (no multi-AZ, basic backup). Observability: Green (full distributed tracing and alerting)."

An informal term for a finding that indicates a serious, potentially deal-breaking risk. In due diligence, red flags may trigger a price adjustment, a requirement for escrow remediation funds, or a deal withdrawal.

"Two red flags were raised in the final report: the entire codebase is in a private Git repo owned by the CTO's personal GitHub account (single person risk + IP ownership issue), and 3 customer databases contain PII with no encryption at rest."