Technical Due Diligence: A Checklist Before You Raise

Sergio Jimenez·October 21, 2026·6 min read

Technical due diligence is not an exam you pass by having clean code. It is an investor working out one thing: whether the engineering can absorb the money without breaking, and whether anything in it could destroy the company's value after they wire.

Knowing what they look for lets you fix the expensive findings while they are still cheap.

What actually gets checked

Area	The question underneath
Ownership of the code	Does the company actually own what it sells?
Licences	Is there a dependency that forces you to open source your product?
Security and data	Is there a breach waiting, or a regulator with a claim?
Key person risk	What happens if one named person leaves?
Ability to ship	Can the team absorb five more engineers and go faster, not slower?
Cost to run	Do the unit economics survive ten times the usage?

Notice that code quality is not a row. It matters only where it affects one of these.

Ownership, which is where deals actually die

This is the one that kills rounds, and it is entirely preventable.

Every person who has written code for you, employee, contractor, co founder who left, an agency, the friend who built the first prototype, must have assigned the intellectual property to the company in writing. A contractor with no IP assignment clause owns what they wrote by default in many jurisdictions. Finding that during diligence is a delay at best.

Check also that the company, not a personal account, owns the repositories, the cloud accounts, the domain, the app store listings and the Stripe account. Founders commonly create all of these personally on day one and never migrate. It is an easy fix in month one and an awkward one in a data room.

Licences

Generate a dependency licence report and read it. You are looking for copyleft licences, GPL and AGPL in particular, in anything you distribute or run as a service. AGPL in a hosted product is the one that genuinely frightens lawyers.

This takes an afternoon with standard tooling and is the cheapest item on this list. It is also the one most likely to produce a surprise, because dependencies arrive transitively and nobody chose them.

Security, at the level investors actually probe

Nobody expects a startup to hold a formal certification at seed. They expect the basics to be unambiguous:

No secrets in the repository, including in its history. Rotate anything that ever was committed, because the history is forever.
Multi factor authentication on cloud, source control, email and the payment processor.
Encryption at rest and in transit, which is mostly a matter of not having disabled defaults.
Named access control, so leavers lose access and you can show who has what.
Backups that have been restored at least once. An untested backup is a belief, not a control.
A written answer for personal data: what you hold, where it lives, how it is deleted on request.

Key person risk

The question is blunt: if your lead engineer resigns tomorrow, what stops?

What reassures an investor is not a hero, it is the absence of one. Architecture decisions written down. More than one person who has deployed to production. A runbook for the recurring operational tasks. Credentials in a shared vault rather than one laptop.

If a single person is the only one who understands the deployment, that is a finding, and it is usually discovered by asking a junior engineer rather than by reading documents.

Ability to ship

Investors are buying future velocity. The signals are unglamorous and easy to produce if you are already working this way:

Automated tests on the paths that touch money and identity. Not everything. Those.
Continuous integration that actually blocks a broken merge.
Separate development, staging and production environments.
Deployments that are routine and reversible rather than events.
Error monitoring and alerting that someone receives.

These are the same practices covered in our guide to choosing an agency, for the same reason: they are what distinguishes a team that can keep going from one that is already slowing down.

Cost to run

Be ready to answer what one customer costs you in infrastructure, and what happens to that number at ten times the volume. If your product uses AI, expect specific questions about token spend per user, because it is the one line item that does not amortise with scale. Our note on cutting an LLM bill covers the levers an investor will assume you know about.

A checklist worth working through

IP assignment signed by every past and present contributor.
Company, not a person, owns repos, cloud, domain, stores and payment accounts.
Dependency licence report with no copyleft surprises.
No secrets in git history, and anything ever committed rotated.
Multi factor authentication everywhere that matters.
A restore from backup performed and dated.
Architecture decisions written down, however briefly.
Two people who can deploy.
Tests and CI on money and identity paths.
Infrastructure cost per customer, with a projection.

Items one to five are where deals are delayed. They are also the five you can finish in a week.

Frequently asked questions

What is technical due diligence?

The review an investor or acquirer runs on your engineering before closing. It covers ownership of the code, dependency licences, security and data handling, key person risk, the team's ability to keep shipping, and what the product costs to run. The underlying question is whether the engineering can absorb the investment without breaking.

What do investors look for in technical due diligence?

Mostly risk, not elegance. Clear IP ownership from every contributor, no copyleft licences in a hosted product, no secrets in the repository, multi factor authentication, tested backups, more than one person who can deploy, and tests on the paths that touch money and identity. Code quality matters only where it affects one of these.

What kills a deal in technical due diligence?

Unassigned intellectual property, most often from a contractor or a departed co founder who never signed an assignment. After that: a copyleft licence in a product you distribute, personal accounts owning company infrastructure, and secrets committed to a repository that were never rotated.

How do I prepare for technical due diligence?

Start with ownership. Confirm every contributor signed an IP assignment and that the company, not an individual, owns the repositories, cloud accounts, domain, store listings and payment accounts. Then run a dependency licence report, scan git history for secrets, enable multi factor authentication everywhere, and perform one restore from backup.

Do I need SOC 2 or ISO 27001 to raise?

Not at seed or Series A in most cases. Investors expect the fundamentals to be unambiguous rather than a certificate. Formal certification becomes relevant when your customers demand it, which usually means selling to enterprise, and that is a commercial trigger rather than a fundraising one.

How long does technical due diligence take?

Typically one to three weeks at seed and Series A, often a single technical call plus a document request and limited code access. It stretches when findings appear, and the ones that stretch it most are ownership questions, because resolving them means tracking down people who no longer work with you.

Where to start

List everyone who has ever written code for the company and confirm each one signed an IP assignment. That single exercise takes a morning and resolves the most common reason a round slips.

If you are heading into a raise and want the engineering looked at before an investor does, talk to us. It is considerably cheaper to find these yourself.