Technical Due Diligence Checklist
What investors actually review in technical due diligence.
A complete checklist covering code quality, security, infrastructure, engineering team, and documentation — with practical commentary on what each finding means for a deal.
What this is
Technical due diligence is about risk, not perfection.
No codebase is perfect. The goal of technical due diligence is not to find a perfect system — it's to understand the risks you're acquiring or investing in, and to price or structure the deal accordingly.
The checklist below covers what experienced reviewers look at. Each item includes practical commentary on what findings actually mean for the deal — not just what to look for, but what to do with what you find.
01
Code Quality & Architecture
Codebase structure and organisation
Is the code organised logically? Can a new engineer understand the structure within a day? Spaghetti code isn't just a maintenance problem — it signals weak engineering practices.
Test coverage and test quality
Unit, integration, and end-to-end test coverage. Low coverage isn't necessarily fatal but predicts future velocity loss. More important: are the tests meaningful, or are they testing implementation details instead of behaviour?
Dependency management and vulnerability audit
Outdated dependencies with known CVEs are one of the most common findings. Tools like Snyk or npm audit expose this quickly. Unmaintained dependencies in critical paths are red flags.
Code duplication and technical debt
Some debt is strategic. Uncontrolled duplication is not. We look for signs that engineers were under pressure to ship without the ability to refactor — a common pattern in agency-built codebases.
Architecture decision records (ADRs) or equivalent
Can the team explain why major decisions were made? Absence of documentation doesn't disqualify a company, but it means every architectural question requires tracking down the original engineer.
Scalability design
Is the system designed for the scale the deal assumes? N+1 query problems, lack of caching, synchronous architectures handling workloads that will need async — these create predictable performance walls.
02
Security
Authentication and authorisation implementation
How are sessions managed? Is there role-based access control? Are there admin endpoints protected only by obscurity? Auth bugs are the most common source of post-acquisition security incidents.
Secrets and credentials management
Are credentials hardcoded, committed to version control, or stored in plaintext? We check git history, environment variable handling, and CI/CD configuration. This is an instant red flag when found.
Input validation and injection prevention
SQL injection, XSS, CSRF — the classics are still the most common. We look at how user input flows through the system and where it's sanitised, parameterised, or missed entirely.
Data encryption at rest and in transit
Is sensitive data encrypted at rest? Is TLS enforced everywhere? For companies handling PII or payment data, this is a compliance question as much as a security one.
Third-party access and API key management
What services have API keys? Where are they stored? Are they scoped to minimum required permissions? A single overpermissioned AWS key with no rotation policy is a material risk.
Incident response and logging
Is there sufficient logging to reconstruct what happened in an incident? Can the team detect a breach, or would they only find out from a customer? This separates organisations that have thought about security from those that assume nothing will happen.
03
Infrastructure & DevOps
Cloud architecture and cost structure
Is the infrastructure appropriately sized for current load? Over-provisioned infrastructure inflates burn rate. Under-provisioned infrastructure is a scaling risk. We look for obvious right-sizing opportunities and hidden costs.
Deployment process and CI/CD
Is deployment automated or manual? Can the team deploy without fear? Manual deployments are one of the strongest leading indicators of slow future development velocity.
Environment parity
Do dev, staging, and production environments match? Divergent environments cause 'works on my machine' bugs and false confidence in pre-production testing.
Monitoring and alerting
Does the team know when something goes wrong, or do they find out from users? Error tracking, uptime monitoring, and meaningful alerting are table stakes for a production system.
Disaster recovery and backup strategy
Are database backups tested? What is the RTO and RPO? 'We have backups' is not the same as 'we have tested restores.' We check whether the backup strategy has ever been validated.
Vendor and infrastructure lock-in
Is the system portable? Deep dependence on a single cloud provider's proprietary services can limit future flexibility and negotiating leverage. This matters more for infrastructure-heavy businesses.
04
Engineering Team
Team composition and seniority
Who actually built this, and are they still there? A system built entirely by contractors who have left is a different risk profile from one built by an in-house team that owns the codebase.
Bus factor
How many engineers could leave before the system becomes unmaintainable? A bus factor of one — one person who understands a critical component — is a material acquisition risk.
Engineering processes and practices
Code review practices, branching strategy, sprint or kanban cadence, documentation culture. Process quality predicts post-acquisition integration difficulty.
Retention and compensation benchmarks
Are key engineers at-market compensation? Founders sometimes undercompensate early engineers. A retention risk in the technical team can emerge quickly post-acquisition.
05
Documentation & IP
Technical documentation quality
Is there a runbook? API documentation? Onboarding documentation for new engineers? Absence of documentation means knowledge is locked in people's heads — which increases transition risk.
Open source licence compliance
Are any GPL-licensed libraries used in ways that create licence contamination risk? This is rare but consequential when found in commercial products.
IP ownership and contractor agreements
Do all contributors — employees, contractors, and agencies — have signed IP assignment agreements? Code built by contractors without IP assignment can create ownership ambiguity that complicates a deal.
Third-party data and API agreements
Are there data licensing agreements that would be affected by a change of ownership? Some data provider contracts include change-of-control clauses that require renegotiation.
Due diligence FAQ
Common questions.
Who commissions a technical due diligence review?
Typically the investor or acquirer — the party making a capital or acquisition decision. The target company provides access. In some cases, founders proactively commission a 'pre-sale' technical review to identify and fix issues before a buyer finds them.
How long does technical due diligence take?
For most startup-sized codebases, 10–14 days from access to final report. Time-sensitive transactions can be compressed to 7 days. Enterprise-scale systems with millions of lines of code may require 3–4 weeks.
Does technical due diligence affect deal valuation?
Yes — both directions. Clean codebases with good practices can support premium valuation. Critical findings like hardcoded credentials, absent test coverage, or significant technical debt can trigger price adjustments, escrow holdbacks, or remediation conditions.
What findings are deal-killers vs deal-adjusters?
Deal-killers are rare but include: fundamental architecture that cannot support the business model, active security breaches, IP ownership disputes, or catastrophic data handling violations. Most findings are deal-adjusters: priced into the deal, addressed through representations and warranties, or remediated as a condition of close.
Should the target company know a technical review is happening?
Yes — transparent due diligence produces better results. Surprise reviews create defensiveness and withholding. The target team can explain context, flag planned improvements, and provide access to information that wouldn't be found in a code scan alone.
Need a technical due diligence report?
We run this entire checklist — and more — for investors and acquirers. Written report, deal implications section, 90-minute walkthrough. NDA signed before access.
Request a due diligence report →