The deal was progressing well. Valuations aligned, terms moving forward, teams excited. Then the technical due diligence arrived — and what the reviewer found changed everything: a monolithic system with no tests, three engineers holding critical knowledge of systems the company depended on, security debt across multiple layers, and an architecture that made integration with the acquirer's stack infeasible.
That scenario is not an exception. It's more common than most people on the financial side imagine. And the cost — in valuation adjustments, post-closing obligations, or a lost deal — is high.
What technical due diligence really is
Technical due diligence is the process of assessing the real state of a company's technological assets before a transaction — whether an acquisition, a Series A and beyond investment, or a merger.
It's not a line-by-line code audit. It's a structured analysis of system health, engineering practices, operational risks, and the ability to scale and evolve the technology.
The goal is not to find reasons to kill the deal. It's to give the acquirer or investor an honest view of what they're buying — and to give the seller the opportunity to explain context that numbers alone don't show.
The six dimensions that need to be assessed
1. Architecture and scalability
Can the system handle growth? Is the current architecture an asset or a liability for the next 3 years? Are there known bottlenecks that only appear at scale? Is architecture debt managed or out of control?
2. Code quality and test coverage
What is the automated test coverage? Does code follow consistent standards? Are there areas of the system nobody can modify without fear of breaking something? What is the production bug rate per month?
3. Security
Are there any critical vulnerabilities in the system? How are secrets and credentials managed? Are there dependencies with known unpatched vulnerabilities? Has the system undergone penetration testing in the last 12 months?
4. Infrastructure and operations
How is the production environment structured? What is the mean recovery time in case of an incident? Is deployment automated and traceable? Is there adequate monitoring and alerting?
5. Dependencies and licenses
What are the third-party dependencies — libraries, services, APIs? Are there software licenses that restrict commercial use or redistribution? Is there single-vendor risk in critical components?
6. People and knowledge
Is system knowledge distributed or concentrated in one or two people? How is the technical documentation? Can the engineering team sustain and evolve the product without the founders?
What tends to surprise
After numerous technical due diligence processes, some patterns appear consistently:
Knowledge concentration is the most underestimated risk. Two engineers who know how the entire system actually works, with no adequate documentation, represent a business continuity risk that directly impacts valuation.
Security was rarely a priority in early-stage startups. Passwords in repositories, outdated dependencies with known CVEs, improvised authentication — these problems appear frequently and have real correction costs.
The architecture doesn't scale the way the pitch deck suggests. When the company projects 10x growth in 18 months, the architecture needs to support that. Many can't — and the refactoring estimate to get there is part of the real cost of the transaction.
When to do it and who should conduct it
Technical due diligence should happen before the term sheet in significant transactions — not after. Problems found before the term sheet are easier to negotiate than post-closing surprises.
The ideal reviewer is a Staff Engineer or senior architect with experience across multiple contexts — not someone from the acquirer's internal team who has bias, and not a generalist who can't assess technical depth.
The typical process takes 5–10 business days and results in a structured report with: executive risk summary, detailed analysis by dimension, and recommendations with priority and effort estimates for correction.
For those being acquired
If you're on the seller's side, technical due diligence is not a threat — it's an opportunity. An experienced reviewer can help articulate what was built, contextualize trade-off decisions that seemed poor on the surface, and prepare documentation that accelerates the process.
Companies that arrive well-prepared for technical due diligence convey confidence. And confidence, in M&A processes, has real value.