How TDD Actually Works
Before diving into what to evaluate, it helps to understand the mechanics of the process itself. TDD typically occurs during a defined window — often 30 to 90 days — after a Letter of Intent (LOI) has been signed but before the deal officially closes. The LOI is a non-binding agreement that says "we intend to buy you at roughly this price, subject to due diligence." During this window, the acquiring company's technical team gets controlled access to the target's systems, documentation, and sometimes personnel.
The primary vehicle for this access is the data room — a secure, access-controlled repository (often a service like Intralinks, Datasite, or even a locked-down shared drive) where the target company uploads documents the buyer has requested. For technical diligence, this typically includes architecture diagrams, infrastructure inventories, CI/CD pipeline configurations, incident post-mortems, security audit reports, engineering org charts, and access to source code repositories. In more thorough diligences, the buyer's engineers may also get read-only access to the target's GitHub or GitLab organization, their cloud console (AWS, GCP, Azure), and their monitoring dashboards.
A typical TDD engagement follows this flow:
- Document Request List (DRL): The acquiring team sends a detailed checklist of documents and artifacts they need. This list often runs to 100+ items covering architecture, security, HR, legal, and financials.
- Data Room Review: Engineers review what's provided, noting gaps. What's missing is often more telling than what's present.
- Technical Interviews: The buyer's engineers interview the target's CTO, VP of Engineering, lead architects, and senior developers. These are structured but conversational — the goal is to validate what the documents claim and probe areas the documents don't cover.
- Code & Infrastructure Review: Hands-on examination of repositories, deployment pipelines, cloud configurations, and monitoring dashboards.
- Findings Report: A structured document categorizing risks as Critical (deal-breaker or major price renegotiation), High (significant price adjustment), Medium (post-close remediation plan required), or Low (acceptable, normal tech debt).
Key Point: What the target company doesn't provide is a signal. If you request incident post-mortems and they say "we don't have any," that means either they've never had an incident (unlikely for any production system) or they don't have a culture of learning from failures. Both are findings worth documenting. A mature engineering organization welcomes the diligence process and has documentation ready. An immature one scrambles to produce it — or can't.