Technical Due Diligence Checklist for Startups

Technical due diligence is an investor's or buyer's check that your technology is what you say it is. It confirms that the product works, that you own it, that it can grow with the business, and that fixing its problems won't eat the money they're putting in. Nobody expects an early-stage product to be perfect. What hurts founders is surprises: problems the reviewer finds that you didn't know about, or knew about and didn't mention.

This guide is written for founders preparing to raise, especially non-technical founders whose product is built by an agency, a freelancer or a small team. It covers what gets checked, what's normal at your stage, what actually worries investors, and what to prepare.

What is technical due diligence?

Technical due diligence (often shortened to "tech DD") is the part of a deal where someone with an engineering background looks under the hood. It often happens after a term sheet or a serious expression of interest, sometimes before, and always before money moves.

Who runs it depends on the deal:

Seed rounds: often light or skipped. A partner with a technical background asks questions on a call, maybe looks at a demo and an architecture sketch.
Series A and later: more common and more structured. The fund's own technical partner or an outside firm reviews documents, the code and the team, then writes a report for the investment committee.
Acquisitions: the deepest version. The buyer is taking on the code, the people and the liabilities, so expect full code access, security review and close attention to licences and ownership.

The questions are the same at every stage. What changes is how deep the reviewer digs, and how much they're willing to accept as "fine for now".

What investors are really trying to find out

A checklist can run to hundreds of items, but every item serves one of five questions:

Does the product work the way you've described it? Features in the pitch deck exist, the numbers you quote come from the system, and the "AI" is what you say it is.
Do you own it? The company holds the rights to the code, the accounts and the data, with nothing that a contractor, a former cofounder or an open-source licence can take back.
Can it grow with the plan? If the business hits the targets in your model, the technology won't need to be rebuilt from scratch to get there.
Can this team deliver the roadmap? The people building it understand it, and the knowledge isn't locked in one person's head.
What will it cost to fix what's wrong? Every product has problems. The reviewer is estimating how much of the new money goes to repairs instead of growth.

If you prepare answers to these five, most of the detailed questions will be easy.

The rule I'd prepare by: no surprises

Every problem the reviewer finds should already be on your list.

A known problem with a plan reads as maturity: "Our test coverage is thin on the billing code. It's the first thing we'll fix after the round, and here's the estimate." The same problem discovered by the reviewer reads as either "the founders don't know their own product" or "the founders hid it". Both are worse than the problem itself.

So the goal of preparing for technical due diligence isn't to fix everything. It's to know everything, fix the few things that can't wait, and write down the rest with a plan.

The technical due diligence checklist

Use this to find gaps before an investor does. You won't be able to answer every item yourself if you're not technical, and that's fine: the point is to know which ones you can't answer, and get them answered.

1. Ownership and IP

This section is where non-technical founders get caught most often, and it has nothing to do with code quality.

Every person who wrote code signed an IP assignment. Employees, freelancers, agencies, cofounders, early "friends helping out". Depending on the country and the contract, code written by a contractor can legally belong to the contractor unless a written agreement assigns it to your company. Check with a lawyer if you're unsure.
The company owns the code repository. It lives in an organisation account the company controls (on GitHub, GitLab or similar), not in the agency's or a freelancer's personal account.
The company owns the critical accounts. Domain, cloud hosting, app store listings, payment provider, email sending, analytics. Each should be registered to the company, with at least two people who can access it.
Open-source licences are known. Most open-source code is fine to use commercially. Some licences (for example GPL and AGPL) can require you to publish your own code under certain conditions. Someone should have checked what's in your product.
Third-party code and content are licensed. Paid libraries, fonts, images, datasets, APIs. Nothing you're using on a free or personal licence that doesn't cover commercial use.

2. Team and knowledge

There's a clear owner of technical decisions. A CTO, a lead developer, a fractional CTO or the agency's tech lead. The reviewer will want to talk to them, and they need to be able to explain the choices made.
More than one person can deploy and fix the product. If your only developer were unreachable for a month, could someone else release a fix?
Key knowledge is written down. How to set up the project, how to deploy, how the main parts fit together. A few honest pages beat none.
The team's size and setup match the roadmap. If the plan says ten new features this year and you have one part-time freelancer, expect that question.
Contracts with agencies and freelancers are in order. Notice periods, handover obligations and who owns the work (see section 1).

3. Architecture and scalability

There's an architecture diagram, and it's current. One page: the main components, the database, third-party services and how data flows between them.
You know what breaks first under growth. Not "it scales", but "at roughly ten times our current load, the database will be the bottleneck, and here's what we'd do".
The technology choices are explainable. Mainstream, well-supported technologies are a safe answer. Unusual choices are fine if there's a reason for them.
No rewrite is planned or needed to reach the next milestone. If one is, say so up front and show the plan and the cost. A rewrite discovered in diligence is one of the most damaging findings.

4. Code quality and technical debt

The code can be maintained by someone new. Readable, reasonably consistent, organised so a new developer can find their way around in days, not months.
Automated tests exist where failure is expensive. Payments, sign-up and login, anything touching customer data. Full coverage isn't the bar; protecting the critical paths is.
Known technical debt is listed. The shortcuts the team took, what each one costs to fix, and which ones matter. Your developers can produce this list in an afternoon if you ask.
Changes are reviewed before they ship. At least a second person looks at code before it goes live, or there's a good reason why not (a solo developer, for example).

5. Security and data

No secrets in the code. Passwords, API keys and access tokens are stored in a secrets manager or environment settings, not committed to the repository.
Customer data is protected. Passwords are hashed with a modern algorithm, sensitive data is encrypted, and access to production data is limited to the people who need it.
Access is managed. Former employees and contractors have been removed from every account. Important accounts use two-factor authentication.
You know which privacy rules apply. GDPR if you have users in the EU or UK, HIPAA if you handle patient data for US healthcare providers or insurers, and so on. You don't need a compliance programme at seed, but you need to know which rules apply to you and roughly where you stand.
You've had at least one security look. A review by an experienced engineer, an automated scan, or a penetration test if your data is sensitive. Investors in regulated markets (health, finance) will expect more.

6. Infrastructure and operations

Backups exist, and someone has restored one. An untested backup is a hope, not a backup.
Deployments are repeatable. A release follows written steps or, better, an automated pipeline, not one person's memory.
You'd know if the product went down. Basic monitoring and alerts, and a rough idea of how often it has gone down this year.
Hosting costs are understood. What you pay per month, what drives the cost, and how it grows with users. A cost that grows faster than revenue is a business problem, and reviewers look for it.

7. Product and roadmap

The demo matches the deck. Anything presented as built is built. If a feature is manual behind the scenes, say so.
Metrics come from the system. User numbers, usage and revenue figures can be traced to real data, not a spreadsheet someone updates by hand.
The roadmap is realistic for the team. The reviewer will compare what you plan to build with who's building it and how fast they've shipped so far.

8. If your product uses AI

You can explain what the AI does and where it comes from. Your own model, a fine-tuned model, or calls to a provider like OpenAI or Anthropic. All three are legitimate; overstating it isn't.
You have the rights to your training data, if you trained or fine-tuned anything.
You know what happens if the provider changes. Prices, rate limits, model updates. Could you switch providers, and roughly what would it cost?
If the product itself was built with AI coding tools, someone experienced has reviewed the code. It deserves a closer look for security and maintainability than code a developer wrote and understands line by line.

Red flags vs normal findings

The question for every finding is whether it's expected for your stage or a sign of something worse. This is roughly how I'd sort them for an early-stage startup:

Usually normal at seed or Series A	Usually a real problem
Thin test coverage outside the critical paths	No IP assignment from people who wrote the code
A monolith instead of microservices	Code or accounts owned by an agency or a former cofounder
Some technical debt, written down with a plan	A rewrite needed to reach the next milestone, not disclosed
Little documentation, but the team can explain the system	One person holds all the knowledge and access
No formal compliance programme yet	Customer data exposed, or secrets in a public repository
Manual steps in deployment	The product doesn't do what the deck says
Mainstream, slightly dated technology	No backups, or backups never tested
A small team	A copyleft licence problem in core code

The left column is negotiable: it may show up as a note in the report, or a condition to fix after the round. The right column can change the valuation, the terms or the decision.

How the process usually works

The details vary by investor, but the shape is usually similar:

Request list. You get a list of documents and questions, often in a shared folder (a "data room").
Documents. You share the architecture overview, team structure, key contracts, policies and anything else on the list.
Interviews. The reviewer talks to whoever leads technology, sometimes to individual developers. Expect one to three calls.
Code and system access. Read-only access to the repositories, sometimes a look at the hosting setup. Not every review includes this at seed; most include it later.
Report. The reviewer writes up findings for the investor, usually as risks ranked by severity, with recommendations. You may or may not see it.
Follow-ups. Questions on specific findings, sometimes conditions attached to the deal.

From request to report, a few weeks is typical. It runs alongside legal and financial due diligence, so it lands at a busy time.

How to prepare for technical due diligence

Six to eight weeks before you raise

Run the checklist above with your lead developer or agency, and mark each item: fine, problem with a plan, or unknown.
Fix ownership first. Missing IP assignments, accounts in the wrong name and code in someone's personal repository take time to sort out, sometimes with a lawyer, and they're the hardest to explain away.
Get an outside opinion on the code if you can't judge it yourself. Better you hear the bad news now, with time to act, than in the middle of a round.
Fix the few urgent things: exposed secrets, missing backups, former contractors who still have access.

Two weeks before

Write a one-page technical overview: what the product is built on, the architecture diagram, who builds it, how releases work, the main risks and the plan for each.
Write down known technical debt and roughly what it would cost to address. Short and honest beats long and polished.
Prepare your technical lead for the interview. They should be able to explain the main decisions and trade-offs in plain language, and say "we know, and here's the plan" about the weak spots.
Collect the documents: contracts with developers and agencies, IP assignments, a list of third-party services and their costs, any security reviews.

During the review

Answer what's asked, accurately. If you don't know, say you'll find out, then follow up.
Raise known problems before they're found. That's the no-surprises rule in practice.
Keep one person coordinating. Requests come in fast; a single point of contact stops contradictory answers.

Technical due diligence questions to prepare for

These come up in some form in most reviews. Have an answer, and ideally a document, for each:

"Walk me through the architecture. What are the main components and how do they talk to each other?"
"Who wrote the code, and do you have IP assignments from all of them?"
"What would break first if usage grew ten times?"
"What's your biggest piece of technical debt, and what would it cost to fix?"
"How does a change get from a developer's laptop to production?"
"When did you last restore from a backup?"
"Who has access to production and customer data?"
"What happens if your lead developer or agency leaves?"
"What open-source software do you depend on, and under which licences?"
"How much do you spend on hosting, and how does it grow with users?"
"What's on the roadmap for the next 12 months, and who will build it?"

If you're not technical, ask your developers to answer these in writing first. Where their answers are vague, or contradict each other, you've found your preparation list.

What a technical due diligence report contains

Reports differ by firm, but most contain the same parts:

Summary for the investor: an overall view and the few findings that matter for the decision.
Findings by area: architecture, code, security, infrastructure, team, IP. Each finding has a severity and a recommendation.
Risks with an estimated cost: how much effort or money it would take to fix the important ones.
Conditions or recommendations for the deal: things to fix before closing, or within a set time after.

You might not see the investor's report. If you run your own review first, you'll have something better: the same kind of report, written for you, while there's still time to act on it.

If an agency or freelancer built your product

This setup is common for non-technical founders. Ownership and continuity (checklist sections 1 and 2) are where it gets caught most often. Two more things come up:

Independence. The reviewer will want to hear the agency's tech lead explain the system. If the agency is slow to cooperate with a review, find that out before an investor does.
What happens after the round. Investors may ask whether you'll keep the agency or build an in-house team, and what that transition looks like.

None of this is a reason not to use an agency. It's a reason to have the paperwork and access in order.

When to get help

You'll get the most from an outside review if:

you're raising in the next few months and can't judge the code yourself
your product was built by an agency, freelancers or AI tools, and nobody independent has looked at it
an investor has already asked technical questions you couldn't answer
you're being acquired and want to know what the buyer will find

This is what a code audit is for: the same kind of review an investor would run, done for you before anyone else looks, with a plain-English report and a plan for what to fix first. I don't sell development, so I have no reason to find more problems than there are. If you're not sure you need a full audit yet, do you need a CTO? covers the lighter options, or message me and tell me when you're planning to raise.