The Short Answer
Technical due diligence for an acquisition or investment covers seven areas: codebase quality and architecture, infrastructure and scalability, security posture, team structure and key-person risk, technology debt, third-party dependencies, and deployment and operations maturity.
The goal is not a report that says "the code is fine." The goal is a risk-adjusted picture of what you are actually buying — what breaks when the team scales, what costs money to fix before it breaks, and whether the technical foundation can support the growth thesis you are underwriting.
What Is Technical Due Diligence and Why Does It Matter for Investors?
Most acquisition or investment risk lives in financial statements. Technical risk lives in a GitHub repo that your financial team cannot read.
A company can show three years of clean revenue, a solid customer base, and a capable founding team — and still have a codebase that requires twelve months of remediation before it can scale to the next customer tier. That remediation is a cost that belongs in your deal model. Technical due diligence puts a number on it.
It also surfaces risks that do not show up in interviews. Founders are not lying when they say the system is stable. They mean it is stable for current load, on current infrastructure, maintained by people who built it and know where the landmines are. That is a different statement than "this system is stable for 5x the current user base after the acquisition team offboards two senior engineers."
Technical DD is the discipline that translates the gap between those two statements into actionable findings and, where possible, dollar figures.
What Areas Does a Technical Due Diligence Review Cover?
A complete technical DD review covers seven areas. Every one of them feeds the risk picture differently.
1. Codebase quality and architecture
Is the code maintainable by a team that did not write it? Are there clear boundaries between system components, or is everything tightly coupled in ways that make changes expensive? Code quality is not about elegance — it is about the carrying cost of future development.
2. Infrastructure and scalability
Where is the system hosted? How is it deployed? What happens at 3x current load, and what is the cost to get there? Cloud spend, auto-scaling configuration, and database query patterns all feed this.
3. Security posture
Authentication and authorization design, secrets management, dependency vulnerability exposure, and compliance posture (SOC 2, HIPAA, PCI if relevant). Security gaps discovered post-close become your liability, not the seller's.
4. Team structure and key-person risk
How many people genuinely understand the system? If the lead architect leaves in month four post-close — which happens — what breaks? Key-person risk is not a soft finding. It is a hard operational constraint with a real remediation timeline.
5. Technology debt
Debt is not automatically bad. Intentional shortcuts taken to hit a launch date are different from neglected infrastructure that has been accumulating for three years. The distinction matters because intentional debt has a known cost; neglected debt often does not.
6. Third-party dependencies
What does the system rely on that it does not control? Vendor lock-in, deprecated libraries, end-of-life frameworks, and critical paths through single-vendor APIs are all risk items. A payment processor integration that runs on an unmaintained library is a remediation ticket the day you close.
7. Deployment and operations maturity
How does the team ship software? Is there a CI/CD pipeline, automated testing, monitoring and alerting, and a rollback procedure? Or does deploying to production require four Slack messages and one specific person at their laptop? The answer tells you a lot about how much operational risk you are taking on.
What Are the Most Common Red Flags Found During Technical DD?
After reviewing codebases across SaaS, marketplace, and enterprise software companies, the same categories appear repeatedly.
- No automated test coverage on critical paths. Every company says the important parts are tested. Verify it. A checkout flow or a data export with zero test coverage is not a philosophical problem — it is a deployment risk that slows every future change.
- Secrets in version control. API keys, database credentials, and service account tokens committed to git history. This is remediable, but it requires auditing every system those credentials touched.
- Single-tenant architecture presented as multi-tenant. Common in companies that added customers one by one and solved tenant isolation manually each time. Migrating to real multi-tenancy post-close is a multi-month project.
- One person who understands the infrastructure. Often the CTO or a founding engineer. When they leave — and post-acquisition, many do — knowledge walks out the door. Bus factor of one is not a technical problem. It is a business continuity problem.
- Undocumented external integrations. Third-party services that are critical to the product but have no runbook, no monitoring, and no internal owner. You find out they exist when they fail.
- Cloud spend with no visibility. Untagged resources, no cost alerting, and spend that has grown with revenue but has never been optimized. The first infrastructure bill post-close surprises many acquirers.
- Deprecated or unmaintained dependencies. A Node.js application running a version that reached end-of-life eighteen months ago is carrying a known security exposure and an unknown upgrade cost.
None of these findings are automatic deal-killers. All of them belong in the deal model as remediable costs with realistic timelines.
How Is a Technical Due Diligence Report Structured?
A useful technical DD report has three parts, in this order.
Executive summary. Two to three pages. What we found, why it matters, what we recommend. Written for the deal team, not an engineering audience. If the deal lead cannot read this section and understand the top three risks, the report has failed its primary job.
Findings by area. The seven areas above, each with findings rated by severity (critical, high, medium, low), a plain-language explanation of the risk, and a rough remediation estimate in time and cost where quantifiable. This section is the working document for post-close planning.
Recommendations. Prioritized list of actions, divided into pre-close conditions (things that should be resolved or renegotiated before the deal closes), year-one priorities, and longer-term improvements. The recommendations section is where the report becomes actionable rather than informational.
Every engagement produces findings in all three severity tiers. A report with only medium and low findings is either a genuinely clean target or a surface-level review. Both outcomes are possible. The structure should make clear which one you have.
When Should You Commission a Technical DD Review?
The right time is after a letter of intent is signed and before the purchase agreement is finalized. At that point you have enough deal momentum to justify the cost and enough runway to act on the findings — either by adjusting the price, adding reps and warranties, or setting pre-close conditions.
Commissioning before LOI is rare but reasonable for a large deal where preliminary technical risk signals are a factor in whether to proceed at all. A lighter-scope preliminary review — two to three days, architecture and security only — can answer that question without the cost of a full engagement.
Post-close is the wrong time. Post-close findings become integration costs, not negotiating leverage.
The other timing factor: the DD review should run in parallel with financial and legal review, not after it. Technical findings often affect the valuation conversation. If technical DD finishes last, you are either delaying close or accepting findings you no longer have time to negotiate.
How Much Does Technical Due Diligence Cost?
Technical DD engagements at 11 Mile Co are $8,000–$12,000 fixed-price. That range covers a full seven-area review with an executive summary, severity-rated findings, and a prioritized remediation plan.
Scope drives where in that range a specific engagement lands: the number of codebases in scope, whether the target has multiple products or a single platform, and the presence of regulated data (HIPAA, PCI) that requires additional security depth.
Fixed-price is deliberate. DD reviews are high-urgency, time-constrained engagements. An hourly or T&M structure creates the wrong incentives — the reviewer runs long, the deal team absorbs unpredictable cost, and the engagement scope drifts. Fixed-price aligns the incentive: we scope the work correctly upfront, and we deliver within that scope.
Every engagement starts with a one-hour scoping call at no cost. That call defines what is in scope, what access we need, and the timeline. If the honest answer is that the target does not warrant a full technical review — a very early-stage company with minimal codebase, for example — we will say so.
Schedule a scoping call to discuss your technical due diligence needs.