Technical due diligence is an investor's check that your product works as described, that the company owns it, that it can scale with the plan in the deck, and that no hidden liability (security, licensing, key-person risk) will surface after the money lands. Prepare by assembling a short data room of architecture, security, delivery and IP documents, fixing the cheap red flags such as secrets in git history and missing IP assignments, and writing down known debt with a plan for each item. Evaluators forgive imperfect code. They do not forgive surprises.
Key takeaways
- Due diligence answers four questions: does it work, do you own it, will it scale with the plan, and what could blow up.
- The data room does more work than the code tour. A current architecture diagram, a debt register and an honest incident history answer half the questions before anyone asks them.
- The cheapest fixes have the largest effect: rotate any secret that ever reached git, collect signed IP assignments from everyone who wrote code, and prove that backups restore.
- Key-person risk is measured, not guessed. Evaluators look at who commits to critical code and who holds production access.
- AI products get extra questions about model dependence, data rights, evaluation evidence and regulation.
- A known problem with a plan is a line item. A hidden problem the evaluator finds is a trust problem, and trust is what a round runs on.
How technical due diligence works
The process varies by investor, but the shape is consistent.
- A request list arrives. Usually a spreadsheet of questions and document requests, sometimes with a deadline measured in days.
- You fill a data room. A shared folder with the documents listed below.
- Interviews. The CTO, usually a senior engineer, sometimes the CEO. Expect an architecture walkthrough on a whiteboard or a shared screen.
- Code and infrastructure review. Read-only repository access or a screen-shared walkthrough. Some evaluators run automated scans for licenses, known vulnerabilities and secrets.
- A report. Findings rated by severity, sometimes with conditions attached to the investment: fix this within a set period after closing.
The evaluator may be a partner with an engineering background, an operating partner, a trusted CTO from the investor's network or an outside firm. They are not trying to fail you. They are trying to tell their partners what they would be buying.
How deep it goes at each stage
| Stage | Typical depth | What they focus on |
|---|---|---|
| Pre-seed and seed | A conversation with the technical founder, perhaps a demo | Can this team build it? Is the core technical risk understood? Does the company own its code? |
| Series A | Data room, interviews, code walkthrough | Architecture fit for the next 18 to 24 months, security basics, delivery practices, key-person risk |
| Series B and later | Often an outside firm, automated scans, infrastructure review | Evidence of scale, a security program, cost structure, whether the organization can grow |
| Acquisition | The deepest: full scans, IP chain of title, integration cost | Everything above, plus what it will cost to integrate or replace |
Deep-tech and infrastructure startups get a deeper review earlier, because the technology is the bet.
What evaluators assess
| Area | What they ask | Good evidence | Red flag |
|---|---|---|---|
| Architecture | How does it work end to end? What breaks at ten times the load? | Current diagram, data flow, key decision records, a scaling plan that names bottlenecks | Nobody can draw it; complexity with no reason, such as many services for a small product |
| Code and delivery | How does a change reach production? | CI on every PR, branch protection, review history, tests on critical paths, delivery metrics | Direct pushes to main, no tests on billing or auth, manual deploys by one person |
| Security | How are data, secrets and access protected? | A security overview, SSO and MFA, a secrets manager, dependency scanning, a pen test report | Secrets in git, shared admin logins, production data on laptops |
| Operations | How do you know when it breaks? | Monitoring, on-call, postmortems, uptime history, a tested restore | Customers report outages first; backups never restored |
| Team | Can this team build the next stage? | Org chart, ownership map, hiring plan | One engineer is the only person who can deploy or change billing |
| IP and licensing | Do you own it, and can you sell it? | Signed IP assignments, a license report, a dependency list | Contractor code without assignment, copyleft obligations nobody tracked, code from a founder's former employer |
| Cost and vendors | What does it cost to run, and what do you depend on? | Cloud cost by service, cost per customer, vendor criticality list | Bills nobody can explain; one vendor with no exit path |
A few areas deserve more than a table row.
Architecture. Evaluators are not looking for a perfect system. They are looking for a team that understands its own system: why it was built this way, where it will strain, and what the plan is when it does. "We know the job queue will need partitioning at roughly the customer count in our plan for next year, and here is the design" is a strong answer. "It scales" is not.
Code quality. Expect them to read the code that handles money, authentication and customer data. Coverage percentages matter less than whether those paths are tested and reviewed. Clean up the obvious: commented-out blocks, hard-coded credentials, dead feature flags.
IP. This is where deals actually stall. Every employee, contractor, agency and founder who wrote code needs a signed assignment of inventions to the company. Code written before incorporation needs its own assignment. Open-source licenses need to be compatible with how you ship: copyleft licenses carry obligations that matter most when you distribute software, and the AGPL extends them to software offered over a network.
The data room: documents to prepare
| Document | What it demonstrates | Notes |
|---|---|---|
| Architecture diagram and data flow | You understand your system | Mark where personal data lives and which third parties receive it |
| Top architecture decision records | Decisions were reasoned | Include one you would make differently today |
| Technical debt register | You know your weaknesses | Severity, impact, effort and plan for each item |
| Technical roadmap for 12 to 18 months | The plan matches the deck | Name the infrastructure work the growth targets require |
| Security overview (two or three pages) | A security program exists | Authentication, access control, encryption, secrets, logging, vulnerability management |
| Pen test report and remediation status | External validation | Mark findings as fixed or accepted, with reasons |
| Compliance reports or readiness plan | Enterprise readiness | SOC 2, ISO 27001 or HIPAA where relevant |
| Incident log and postmortems, last 12 months | Operational honesty | Link each to its action items and their status |
| Uptime or SLO history | Reliability | Exported from monitoring, not recalled from memory |
| Delivery metrics | Engineering health | Deployment frequency, lead time, change failure rate |
| Backup and disaster recovery plan | Resilience | Date and result of the last restore test |
| Dependency and license report (SBOM) | IP hygiene | Copyleft and unknown licenses flagged |
| IP assignment agreements | Ownership | Every employee, contractor and founder |
| Org chart and ownership map | Team risk | Who can deploy, who knows each critical area |
| Access inventory | Least privilege | Who has production, cloud admin and database access |
| Cloud and vendor cost breakdown | Unit economics | By service and per customer |
| Critical vendor list | Dependency risk | An exit plan for the top three |
If you hold a SOC 2 report, it answers a large share of the security questions on its own. If you are on the way, our SOC 2 guide for startups shows what an auditor will expect, which overlaps heavily with what a diligence team asks. For the debt register, our guide to technical debt management has a format that works.
Generate the evidence; do not write it from memory
Documents written from memory drift from reality, and evaluators notice. Generate what you can from the systems themselves.
Secrets in git history. Scan every repository, including old ones. If a live credential turns up, rotate it first; rewriting history comes second, because clones and forks already have it. Gitleaks is a good alternative to the tool shown here.
trufflehog git file://. --results=verified,unknownDependencies, vulnerabilities and licenses. Produce a software bill of materials, scan it and summarize licenses per ecosystem.
syft dir:. -o cyclonedx-json > sbom.cdx.json
grype sbom:./sbom.cdx.json --fail-on high
npx license-checker --summary
pip-licenses --format=markdownKey-person risk. Look at who has actually changed the critical code in the last year. If one name dominates billing or infrastructure, say so and show the plan.
git shortlog -sn --no-merges --since="12 months ago" -- src/billing src/auth infra/Review latency. The median hours from pull request opened to merged, over the last 200 merges. Our post on engineering metrics defines the delivery metrics evaluators usually ask for.
gh pr list --state merged --limit 200 --json createdAt,mergedAt \
| jq '[.[] | ((.mergedAt | fromdate) - (.createdAt | fromdate)) / 3600] | sort | .[length / 2 | floor]'Restore evidence. Restore last night's backup into a scratch database and check that the data is there. Record the date, the duration and the result.
createdb restore_check
pg_restore --dbname=restore_check --no-owner latest.dump
psql -d restore_check -c "select count(*) from orders;"Access inventory. On AWS, the credential report lists every IAM user, their MFA status and their key ages. Other clouds have equivalents.
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > credential-report.csvAI products get extra questions
If the product depends on machine learning or LLMs, expect a second set of questions.
- Model and provider dependence. What happens if the provider raises prices, deprecates the model you use or has a long outage? Show the abstraction layer and the evaluation suite you would use to qualify a replacement model.
- Evaluation evidence. How do you know quality did not regress last release? A versioned evaluation set with tracked results is the answer. Anecdotes are not.
- Data rights. Do your customer contracts allow the way you use their data for retrieval or fine-tuning? Do your provider's terms allow training on your data, and have you opted out where needed?
- Security of the AI surface. Prompt injection, tool permissions for agents and data leakage between tenants in retrieval.
- Regulation. If you sell into the EU, which obligations under the AI Act apply to your use case. Our summary of what changed on 2 August 2026 is a starting point.
- Inference cost per unit. What one customer action costs in model calls, and how that changes with scale.
- Claims versus reality. If the deck says "proprietary model" and the code calls a third-party API with a prompt, the evaluator will find out within an hour.
Red flags and how hard they are to fix
| Red flag | Why it worries investors | Effort to fix |
|---|---|---|
| Missing IP assignments | The company may not own its product | Low technically, but legal work can delay closing |
| Live secrets in git history | Possible existing compromise | Low: rotate in hours, then clean up |
| Never-tested backups | One bad day could end the company | Low to test; more if the test fails |
| One person can deploy or change billing | Key-person risk | Medium: weeks of pairing and documentation |
| Customer data in development environments | Breach and compliance exposure | Medium: masking or synthetic data |
| No tests on money paths | Every change risks revenue | Medium: weeks |
| Unmanaged copyleft obligations | Forced disclosure or a rewrite | Medium to high, depending on how the code is used |
| Architecture cannot support the plan in the deck | The plan is not credible | High: needs an honest roadmap, not a quick fix |
| Misrepresentation | Trust | Not fixable during the deal |
A 30-day preparation plan
Week 1: inventory. Run the scans above. List every contractor and agency that touched code and check their agreements. Export the access inventory. Draw the architecture as it is, not as it was planned.
Week 2: fix the cheap red flags. Rotate exposed secrets. Remove stale accounts and access. Enforce SSO and MFA everywhere it is available. Turn on branch protection. Run and record a restore test.
Week 3: write. The debt register, the top decision records, the security overview, incident summaries and the technical section of the roadmap. Keep each document short; evaluators read many of them.
Week 4: rehearse. Have an engineer from outside the company run a mock interview. Practice the ten-minute architecture walkthrough until it is clean.
Questions the CTO should be able to answer without notes:
- Walk me through what happens, system by system, when a customer does the core action.
- What breaks first at ten times today's load, and what is the plan?
- Tell me about your worst incident in the last year and what changed afterwards.
- What would you rebuild if you had a quarter with no feature work?
- Besides you, who can deploy, roll back and restore the database?
- Where does customer data live, and who can read it?
- What does it cost to serve one customer, and how does that change with scale?
Common mistakes that stall a round
Starting when the request list arrives. The fixes in week two are quick; collecting signatures from a contractor who left two years ago is not. Start when you start talking to investors.
Stale documents. An architecture diagram that does not match the code tells the evaluator that nobody maintains documentation, and makes them doubt the rest of the data room.
Hiding incidents. Outages leave traces: status pages, customer emails, monitoring history. An incident you disclosed with a postmortem is a sign of maturity. One the evaluator discovers is a sign of something else.
Agency code without assignment. An outsourced MVP built under an agency contract that never transferred IP is one of the most common blockers. Read the contract now.
Shared root credentials. A cloud root account or database admin password shared over chat among the founding team. Move to individual accounts with MFA and lock the root account away.
Production data as test data. A copy of the production database on a developer laptop is a breach waiting for a lost bag. Use masked or synthetic data.
Frequently Asked Questions
What is technical due diligence?
Technical due diligence is the review an investor or acquirer runs on a company's technology before committing money. It checks that the product works as described, that the company owns its code, that the architecture and team can support the business plan, and that there are no hidden security, licensing or key-person risks. The result is usually a report with findings rated by severity.
What do investors look for in technical due diligence?
Investors look at architecture and scalability, code quality and delivery practices, security, operational maturity, the engineering team and IP ownership. They want evidence that the team understands its own system, ships changes safely and knows its weaknesses. Clear documentation and honest answers about known problems count for more than perfect code.
How long does technical due diligence take?
It ranges from a single conversation at seed stage to several weeks for later rounds and acquisitions. The biggest variable is how prepared the company is, because waiting for documents, access and signatures takes longer than the review itself. A prepared data room can shorten the process considerably.
What documents are needed for technical due diligence?
Most evaluators ask for an architecture diagram, key decision records, a technical debt register, a security overview, pen test and compliance reports, an incident history, backup and recovery evidence, a dependency and license report, IP assignment agreements, an org chart and a cost breakdown. Generate as much as possible from real systems rather than writing it from memory. Keep each document short and current.
Can technical debt kill a funding round?
Technical debt rarely kills a round on its own, because evaluators expect startups to carry some. What causes problems is debt the team does not know about or hides, debt that blocks the growth plan in the deck, and specific red flags such as missing IP assignments or exposed secrets. A written debt register with a plan for each item turns most debt into a routine finding.
Do seed-stage startups go through technical due diligence?
Usually only lightly. At seed stage, investors mostly assess whether the technical founders can build the product and whether the company owns its code. Deep-tech and infrastructure startups get a deeper review earlier, because the technology itself is the bet.
Need help preparing for due diligence?
We are senior engineers who build and run production systems: if we built it, we are on the pager. That makes us practical reviewers. We can run a pre-diligence review of your code, infrastructure and security, help you fix what matters before investors look, and prepare your team for the technical interviews.