Advanced Business Tech #technical-due-diligence #M&A #architecture-review #bus-factor

Assessment Scope & Process

5 exercises — master technical due diligence process vocabulary: TDD scope and M&A timing, architecture review language (coupling, SPOF, scalability ceiling), code audit metrics (test coverage, CVEs, CI/CD pipeline), team assessment vocabulary (bus factor, key person dependency, documentation quality), and deliverable vocabulary (RAG rating, deal-breaker, risk register, price chip).

0 / 5 completed

TDD quick reference

TDD scope: architecture, codebase, tech debt, team, processes, infrastructure. Occurs during due diligence period after LOI is signed.
Architecture review: coupling (tight = high risk), SPOF count, scalability ceiling. Key probe: "What breaks first at 10x load?"
Code audit metrics: test coverage (≥80% benchmark for critical paths), CVEs in deps (critical = immediate liability), CI/CD pipeline maturity, dependency staleness.
Team assessment: bus factor (how many people can you lose before project halts?), key person dependency, knowledge concentration, documentation quality.
RAG rating: Red = deal-breaker (pre-close remediation or price chip required); Amber = manageable risk with remediation path; Green = acceptable.
Deliverable components: executive summary, technical findings, risk register, remediation roadmap.

1 / 5

A private equity firm hires a CTO-for-hire to conduct technical due diligence on a Series B startup before a $40M investment. The CTO explains: "Technical due diligence is not just a code review. It's an end-to-end assessment of the company's technical risk. Let me walk you through what that actually covers."

What is technical due diligence, what typically falls within its scope, and when in an M&A or investment process does it occur?

TDD is the acquirer's or investor's risk management tool. Every dollar of undetected technical risk that crosses the transaction is effectively a hidden cost that the buyer inherits.

TDD scope overview:

Domain	What is assessed	Example finding
Architecture	Design quality, scalability ceiling, resilience, coupling	"Single database with no read replicas; cannot scale past 5,000 concurrent users"
Codebase	Code quality metrics, test coverage, CI/CD pipeline	"12% test coverage on core payment module; no automated regression testing"
Technical debt	Known issues, remediation cost estimate, debt categories	"Estimated €200K remediation to modernise the legacy authentication module"
Team	Bus factor, key person risk, documentation, culture	"Bus factor of 1 on core ML pipeline — single engineer holds all knowledge"
Infrastructure	Cloud costs, vendor dependency, resilience, lock-in	"Deep AWS proprietary service dependency; migration to Azure estimated at 12 months"

Transaction process vocabulary:
• LOI (Letter of Intent) — a non-binding letter expressing intent to acquire; signals the start of the due diligence period
• Due diligence period — the window (typically 30–90 days) during which buyers examine the target in detail; TDD occurs here
• Escrow clause — a deal mechanism that holds back part of the purchase price until specific technical findings (e.g., tech debt remediation) are confirmed complete

Key vocabulary:
• Technical due diligence (TDD) — systematic pre-transaction assessment of technology risk: architecture, code quality, tech debt, team risk, infrastructure, and process maturity
• Deal-breaker — a TDD finding severe enough to either terminate the deal or require fundamental renegotiation of terms
• Bus factor — the minimum number of team members whose departure would cause catastrophic knowledge loss or project failure; "bus factor of 1" = extreme key person risk

2 / 5

During a TDD engagement, the lead assessor asks the target CTO to walk through their system architecture. The assessor's internal notes focus on: "coupling assessment, single points of failure, and the critical question: 'How would this architecture cope with 10x current load?'"

What vocabulary and analytical framework do technical due diligence assessors use when reviewing system architecture?

Architecture review answers the investor's core question: "Is this technology an asset or a liability?" A well-architected system is a competitive moat; a fragile, tightly coupled monolith with multiple SPOFs is a hidden liability that will require expensive remediation post-acquisition.

Architecture assessment checklist vocabulary:

Assessment area	Healthy finding	Risk finding
Coupling	Service boundaries clear; loose coupling; API-first	Tightly-coupled monolith; no service isolation; direct DB calls across modules
SPOF	All critical components have redundancy; fallback paths defined	Single DB, single queue, single 3rd party dependency with no fallback
Scalability ceiling	Horizontal scaling proven; load tested to 5x current; stateless services	No load tests; vertical scaling only; shared state prevents horizontal scale
Compliance exposure	PII data mapped; GDPR controls documented; encryption at rest and in transit	PII stored unencrypted; no data residency controls; GDPR exposure unquantified

Architecture review phrases used in TDD context:
• "Walk me through your system diagram — how do your core services communicate?"
• "What happens if your primary database becomes unavailable for 30 minutes?"
• "If you 3x your user base overnight, what component would break first?"
• "Are there any third-party dependencies where if that vendor goes down, you go down?"

Key vocabulary:
• Coupling assessment — evaluating the degree of interdependency between system components; tight coupling = high change risk; loose coupling = maintainable, scalable
• Single point of failure (SPOF) — a component whose failure would cause total system failure; SPOF count is a direct measure of resilience risk
• Scalability ceiling — the load level at which the current architecture would require significant redesign rather than just infrastructure scaling
• 10x question — a TDD probe: "Can this architecture handle 10x current load?" Used to identify scalability ceilings and architectural redesign risk

3 / 5

The TDD team reviews the target company's codebase. The lead assessor produces a code health summary with metrics including: "test coverage of 18%, three critical CVEs in dependencies, build pipeline with no automated security scanning, and no documented branching strategy."

What vocabulary and metrics do TDD assessors use when auditing a company's codebase?

Code audit findings in a TDD directly translate to investment risk quantification: low test coverage = higher change risk post-acquisition; unpatched CVEs = immediate security liability; no CI/CD = deployment risk. Each finding should have a remediation cost estimate attached.

Code health indicators table:

Metric	Healthy	Red flag
Test coverage	≥80% on critical paths; meaningful tests (not just line coverage)	<18% overall; 0% on payment/auth/data modules
CVEs in deps	Zero critical/high CVEs; active dependency update practice	3+ critical CVEs in production deps; no Dependabot/Snyk in place
Dependency staleness	Packages updated within 12 months	Core framework 2+ versions behind; EOL (end-of-life) runtime
CI/CD pipeline	Automated build, test, SAST, deploy on every merge	Manual deployments; no automated tests in pipeline; no SAST
Branching strategy	GitFlow or trunk-based dev; mandatory PR review	Commits directly to main; no code review; single long-running branch

Key vocabulary:
• Test coverage — the percentage of production code paths exercised by automated tests; low coverage = high change risk; a direct measure of engineering quality and maintenance burden
• CVE (Common Vulnerabilities and Exposures) — a publicly known security vulnerability in a library or component; critical CVEs in production dependencies = live security liability
• Dependency staleness — the age of third-party packages relative to their current release; stale dependencies signal neglectful maintenance and accumulating security debt
• SAST (Static Application Security Testing) — automated code analysis to detect security vulnerabilities (injection flaws, insecure cryptography, hardcoded credentials) without executing the code

4 / 5

After the technical architecture and code review, the TDD assessor interviews the engineering team. She pays particular attention to bus factor, documentation quality, and key person dependency. She notes: "A company where no one can explain how the core system works without calling a specific person — that's a major risk in any acquisition."

What does team assessment involve in TDD, and what makes these findings significant to an acquirer?

Technical talent and institutional knowledge are, in many technology acquisitions, the primary asset being purchased. Team assessment findings go directly into deal structure: retention packages, earn-outs, and employment guarantees are all driven by TDD team risk findings.

Team assessment vocabulary in TDD reports:

Finding	Report language	Deal impact
Bus factor of 1	"Critical knowledge concentration risk: the ETL pipeline is understood only by one senior engineer"	Retention clause; 2-year employment guarantee; knowledge transfer plan pre-close
Moderate bus factor (3+)	"Knowledge is reasonably distributed across 3 senior engineers; manageable post-acquisition"	Standard retention packages; monitored in 90-day integration plan
No onboarding docs	"Documentation culture is immature; no onboarding guide; tribal knowledge risk"	Documentation sprint added to integration plan; additional integration cost
Founder dependency	"Founding engineer is the architect and sole reviewer of production deployments; departure is a critical path risk"	Earn-out conditioned on 18-month post-acquisition employment

Key vocabulary:
• Bus factor (also: truck factor) — the minimum number of team members whose simultaneous departure would critically impair the project; bus factor of 1 = irreplaceable single point of failure in human capital
• Key person dependency — a specific individual whose departure would significantly damage the acquiree's business continuity, product quality, or customer relationships
• Knowledge concentration — the degree to which critical institutional knowledge is held by a small number of individuals; high concentration = high post-acquisition integration risk
• Earn-out — a deal structure where part of the acquisition price is paid contingent on future performance metrics or on key personnel remaining employed post-acquisition

5 / 5

The TDD engagement concludes. The lead assessor presents findings to the investment committee in a summary meeting. She opens with: "I'll walk you through our overall rating and the individual findings. We use a Red-Amber-Green system. We have two Red items — which in our framework are deal-breakers unless addressed. The rest are Amber — manageable risks with a remediation path."

How does the TDD deliverable vocabulary work — what are the components of an assessment deliverable and what do the rating categories mean?

The TDD report is the document that negotiations will reference — every Red finding can become a renegotiation lever. Understanding the language of TDD deliverables is essential for both the assessor and the target company's CTO who needs to respond to findings.

TDD deliverable structure:

Section	Audience	Content
Executive summary	Investors, board, CFO	Overall RAG, top 3 risks, deal recommendation
Technical findings	CTO, technical advisors	Domain-by-domain detailed findings with evidence
Risk register	Integration team, deal team	All risks with ID, description, RAG, mitigation
Remediation roadmap	Post-acquisition integration team	Prioritised actions, estimated effort, cost, timeline

RAG rating application language:
• "This is a Red finding. The company has three critical CVEs in production that are actively exploited in the wild. This cannot close as-is — we recommend either remediation before close or a $500K price adjustment with escrow."
• "The bus factor finding is Amber. The knowledge is concentrated in two engineers but both are willing to sign 24-month retention agreements. We recommend including retention terms in the deal structure."
• "Infrastructure and DevOps practices are Green — CI/CD is mature, no vendor lock-in concerns, cloud costs are well-optimised."

Key vocabulary:
• RAG rating (Red/Amber/Green) — a standardised finding severity system in TDD: Red = deal-breaker requiring pre-close remediation or price adjustment; Amber = manageable risk with clear remediation path; Green = acceptable, no action required
• Deal-breaker — a Red TDD finding that must be remediated before deal close or will cause the deal to be restructured or terminated
• Price chip — a reduction to the agreed purchase price based on TDD findings; translates risk findings into quantified deal value impact
• Risk register — a structured table of all identified risks with their description, severity, current status, and recommended mitigation; the primary output for the integration team