The complete technical due diligence checklist for investors
In startup investing, technical due diligence (technical DD) is at least as important as financial DD. Yet many investors lack a technical background, so technical DD tends to stay shallow. This article lays out a practical framework for executing technical DD in a way that minimizes “we did not see that coming” outcomes after the round closes.
The purpose and scope of technical DD
The purpose of technical DD breaks down into two things: surfacing risk, and verifying the basis for valuation.
Surfacing risk
- Whether the product can scale per the business plan
- The size of technical debt and the cost of paying it down
- Security and compliance risk
- Concentration risk in technical talent (dependence on specific individuals)
- Ownership of intellectual property and any third-party license issues
Verifying the basis for valuation
This is where you assess whether the technical assets — code, architecture, patents, data — are actually proportional to the claimed business value. It is especially important when the company asserts that AI or data utilization is the core of its competitive advantage; that claim deserves technical scrutiny.
Checklist: Seven evaluation domains
1. Architecture and scalability
| Item | Healthy | Watch out |
|---|---|---|
| Infrastructure diagram | Exists and is current | Missing or outdated |
| Track record of scaling up | Demonstrated | Untested |
| Redundancy of major components | In place | Single points of failure |
| Database design | Properly normalized, indexed | N+1 problems, full scans as the norm |
| Microservices vs. monolith | Right-sized for the company | Over-decomposed, or a monolith blocking growth |
Recommended question: “If your user base grew 10x on the current architecture, where would the bottleneck be? Roughly how much engineering effort would it take to remove?“
2. Code quality and technical debt
When you read the code directly, look at the following:
- Test coverage: presence and runnability of unit and integration tests
- Documentation: API specs, environment setup steps, deployment runbooks
- Dependency management: how often libraries are updated; presence of EOL dependencies
- Code review process: rules around PR reviews; whether merges happen without an approval
A useful way to size the technical debt is to ask engineers, “Name three places you would refactor right now if you could.”
3. Security and compliance
The security view shifts heavily by industry, but the minimum items below are non-negotiable.
Authentication and authorization
- Proper password hashing (bcrypt, argon2, etc.)
- Sound session management
- Authorization on the API surface (per-endpoint permission control)
Data protection
- Encryption of personal data at rest and in transit
- Consistency between the privacy policy and the actual implementation
- Support for data deletion and export (GDPR, Japan’s APPI, and equivalents)
Infrastructure security
- Access control and audit logs for production environments
- Secret management (no hardcoded secrets in environment variables or code)
- Known vulnerabilities in dependencies (use of
npm audit, Dependabot, etc.)
4. Development process and organization
| Item | Detail |
|---|---|
| Deployment frequency | Weekly or better is healthy; monthly or worse warrants questions |
| Incident response | SLA definition, history of past downtime |
| Onboarding | How long until a new engineer can ship a PR |
| Branch strategy | Use of main / develop / feature and the operational rules around them |
| CI/CD | Automated test execution and deployment automation |
The simplest gauge of a healthy development process is: “Can you deploy yesterday’s work today?” If deployment depends on a particular person or a particular day of the week, you have organizational risk.
5. Engineering talent and team structure
Key-person dependency risk
If 80% or more of code contributions concentrate on a single person, that person leaving is a risk that can halt product development. You can verify this from the Git contributor graph or from how PRs are assigned.
Hiring pipeline
- Engineering hiring success rate (screening pass rate, offer acceptance rate)
- Standardization of technical exercises and the interview process
- Degree of CTO involvement in hiring
Attrition
Look at the engineering attrition rate over the past two years and the reasons for those departures. High attrition is a sign that something is wrong with technical debt, organizational culture, or compensation.
6. Intellectual property
- Patents and trademarks: filing status and contribution to competitive advantage
- Open source usage: whether copyleft-licensed OSS is embedded into the service
- Code ownership: rights assignment for outputs from contractors and outsourced development
- Employee agreements: state of invention assignment clauses
7. Product metrics and technical health
| Metric | How to verify |
|---|---|
| Uptime | Disclosure of monitoring dashboards |
| Error rate | Inspection of error trackers like Sentry |
| Page load time | Core Web Vitals numbers |
| API latency | p95 / p99 response times |
| Deployment failure rate | CI/CD logs |
Who runs the technical DD
When investors run technical DD themselves, the limit they hit is the depth of specialist knowledge. We recommend bringing in external technical DD specialists in the following situations:
- AI, ML, or other specialized technical areas are central to competitive advantage
- The round size exceeds roughly USD 1 million (around JPY 100 million)
- You plan to provide value-up support after the investment
A technical DD engagement typically completes in two weeks to one month. The cost runs from a few thousand to several tens of thousands of US dollars, but it functions as insurance against the post-investment surprises.
Structure of a technical DD report
The completed technical DD report should include the following:
- Executive summary: overall rating (5-point scale) and the top three risks
- Architecture assessment: present state and future scalability
- Code quality assessment: scale of technical debt and estimated cost to address
- Organization and process assessment: risks in the development setup and improvement proposals
- Security assessment: critical risks and the priority remediation items
- Post-investment technical support plan: a prioritized roadmap for what to fix first
Closing thoughts
Technical DD is not “looking for problems.” It is “gathering information to raise the probability of post-investment success.” There is no perfect product. What matters is the size and solvability of the risk, and whether the management team is accurately aware of that risk.
Tied Inc. supports investors with technical due diligence. See our services for investors for details.