Valuations aligned, terms moving, integration kickoff booked. Then the technical due diligence report points to a monolith with no tests, three engineers holding the knowledge of critical systems, dependencies with open CVEs, and an architecture that cannot talk to the acquirer's stack.
Reviewers find that combination more often than the finance team expects. The price shows up as a valuation adjustment, a post-closing obligation, or a deal that dies.
What technical due diligence measures
Technical due diligence assesses the real state of a company's technology assets before the transaction closes: an acquisition, a Series A round or later, a merger.
The review team does not read code line by line. It measures system health, engineering practice, operational risk, and the product's room to grow alongside the business plan. Brad Feld and Jason Mendelson walk through the diligence and term sheet sequence in Venture Deals (Wiley, 2019).
The report serves both sides. The buyer sees what it is buying. The seller gets room to explain decisions the numbers alone leave out.
Six dimensions in the assessment
1. Architecture and scalability
The reviewer compares the architecture against the 18-month growth curve in the business plan, looks for bottlenecks that already show up under load, and asks who owns the architecture debt.
2. Code and tests
The report measures automated test coverage, flags the areas nobody modifies without breaking neighbors, and pulls the monthly production bug rate. Michael Feathers shows in Working Effectively with Legacy Code (Prentice Hall, 2004) that untested code turns into code nobody touches.
3. Security
The search covers open critical vulnerabilities, secrets committed to the repository, dependencies with published CVEs, and the date of the last penetration test. Priority comes from the OWASP Top 10 (2021).
4. Infrastructure and operations
Operations contribute automated, traceable deploys, mean time to recovery on incidents, and monitoring that fires alerts. The Google SRE book (Beyer, Jones, Petoff, and Murphy, O'Reilly, 2016) treats these as the baseline for running a service.
5. Dependencies and licenses
Dependencies come out as a list: libraries, services, APIs, licenses that restrict commercial use, and single vendors behind critical components.
6. People and knowledge
The final test is a headcount. Add up who knows each critical system. When the whole system lives in two people, business continuity risk enters the assessment.
The findings that show up most
Knowledge concentration. Two engineers know how the entire system works and none of it is written down. When one of them leaves, the buyer books a continuity risk and takes it off the valuation.
Deferred security. A password committed to a repository, a dependency carrying a two-year-old CVE, authentication built over a weekend. Each fix has a price, and the buyer totals them in the integration budget.
Architecture against the plan. The pitch projects 10x growth in 18 months, and the system reaches it only after refactoring. The estimate for that refactoring joins the cost of the deal.
Who runs it and when
Book the technical diligence before the term sheet. A problem found before the term sheet joins the negotiation. The same problem found after it becomes a last-minute concession.
The right reviewer is a Staff Engineer or senior architect who has worked across several contexts. Will Larson details that scope in Staff Engineer (O'Reilly, 2021). The acquirer's own team grades its own operation, and a generalist without technical depth misses the problems that matter.
The process takes 5 to 10 business days and returns a report with an executive summary, dimension-by-dimension analysis, and prioritized fixes with effort estimates.
The seller's side
If you sit on the selling side, you open the material before the reviewer arrives. An experienced reviewer helps you explain what exists, give context to trade-offs that look poor on the surface, and organize the documentation that speeds up the schedule.
A company that walks in with code, metrics, and written decisions earns trust on the first day in the data room.
