What Investors Actually Ask in Technical Due Diligence (and How to Prepare)

Technical due diligence is the part of a funding round where someone who understands software examines yours. An investor is about to wire you a large amount of money. Before they do, they want to know whether the technology behind your numbers is an asset or a liability.

Most founders prepare obsessively for the commercial questions and walk into the technical review cold. That is backwards. Commercial diligence rarely kills a deal on its own. Technical diligence does, and when it does not kill the deal it quietly reprices it.

This guide covers what reviewers actually look at, the questions they ask, where founders lose deals, and what you can realistically fix in the time you have.

When due diligence actually happens

The depth of the review scales with the cheque and the stage:

• **Pre-seed and seed:** often light. An angel or seed fund might have a technical partner spend an hour with your lead engineer, or skip the review entirely. Do not read too much into an easy ride here.
• **Series A onwards:** a real review. Expect a specialist firm or the fund's own technical team to spend days in your codebase, your infrastructure, and your contracts. They will produce a written report your investors read closely.
• **Acquisition:** the deepest look you will ever get. The buyer's engineers will read your code, your commit history, your incident logs, and your supplier agreements. Anything you hoped nobody would notice, they will notice.

The pattern that matters: every stage assumes you fixed the things the previous stage let slide. A seed investor forgives a solo contractor and no tests. A Series A reviewer does not.

Architecture and scalability

The reviewer wants to know whether the system can grow with the plan you just pitched. If your deck says 10x users in 18 months, they will test whether the architecture survives that.

Questions to expect:

• What happens when traffic grows 10x? Which component falls over first, and do you know that from a load test or a guess?
• Where are the single points of failure? One database, one region, one server that someone restarts by hand?
• Why did you choose this stack, and what would you change now?
• What is the most fragile part of the system, and what is the plan for it?

You do not need a perfect architecture. Early-stage systems are allowed to be simple. What reviewers punish is not knowing. "The job queue is our bottleneck, here is the migration plan" reads far better than a confident claim that nothing can break.

Code quality and delivery

Nobody expects beautiful code at Series A. Reviewers look at whether the team can ship changes safely and repeatedly, because that is what their money buys.

• How does code get from a laptop to production? A pipeline, or a person with SSH access and nerve?
• What is the test coverage on the paths that make you money? Signups, payments, the core workflow.
• How long does a new engineer take to make their first meaningful change? Days is good. Months is a finding.
• How often do releases go wrong, and how do you roll back?

A useful self-test before the review: pick a small feature and trace its path to production. If the honest answer involves one specific person doing undocumented steps from memory, you have found what the reviewer will find.

Security and data protection

For UK companies this section has grown teeth. Reviewers know that a data incident after they invest is their problem too.

• Who has access to production, and is it more people than need it? Are those accounts individual or shared?
• Where do secrets live? A secrets manager, or a .env file that four ex-contractors still have copies of?
• What personal data do you hold, where, and under what lawful basis? Can you actually delete a user when they ask?
• Have you had incidents, and did you handle them properly? A well-handled incident is survivable. A hidden one that surfaces during diligence is not.

On UK GDPR specifically: reviewers check posture, not perfection. A data map, a retention policy, and honest answers go a long way. Get your solicitor to check anything you are unsure about before the review does it for you.

IP and ownership

This is the section that kills deals, and it has nothing to do with code quality. The investor is buying your technology. First they check that you own it.

• Did every contractor and agency sign an IP assignment clause? In the UK, contractors own what they write unless a contract says otherwise. This surprises many founders at the worst possible moment.
• What open-source licences are in your dependency tree? Permissive licences are fine. Copyleft licences in the wrong place raise questions you want answered before the reviewer asks them.
• Who owns the accounts? The domain, the cloud account, the app store listings, the GitHub organisation. If any of these sit under a departed co-founder's personal email, fix that this week.

Unassigned contractor IP is the classic fail. The fix is usually a retrospective assignment deed, which is straightforward when the contractor is friendly and expensive when they realise they have leverage. This is solicitor territory, and it is much cheaper to visit early.

Key-person and vendor risk

The reviewer asks a blunt question: what happens if the one person who understands this system leaves the week after we invest?

• Is there any part of the system only one person can operate or explain?
• If your development agency walked away with 30 days' notice, could anyone else pick up the codebase? Do you even have full access to it?
• Are the people who matter locked in with sensible notice periods and, where appropriate, equity that vests?

Agency-built products get particular scrutiny here. If the agency holds the repository, the cloud account, and all the knowledge, the reviewer sees a company that does not control its own product. At minimum, hold your own accounts and make sure handover documentation exists before the review starts.

Documentation

Nobody fails diligence for thin documentation alone, but good documentation changes the tone of the whole review. It signals a team that knows its own system.

The short list that earns the most credit: an architecture diagram that matches reality, a README that gets a new engineer running locally, a deployment runbook, an incident log, and a register of who has access to what. Five documents. A focused week of work if the knowledge exists in someone's head.

Where founders lose deals

Reviews rarely fail on a single dramatic discovery. They fail on patterns. The ones we see cost founders real money:

1. Contractor IP that was never assigned, discovered when the investor's lawyers request the contracts.
2. A founder who cannot answer basic questions about their own system and visibly depends on an agency for every technical sentence.
3. Production access and secrets shared with people who left the company years ago.
4. A demo that works and a codebase that shows the demo is held together by hand.
5. Confident answers that the review then contradicts. Reviewers forgive weaknesses. They do not forgive discovering that you hid them.

The consequence is usually not a dead deal. It is a reduced valuation, a chunk of the round held in escrow, or completion conditions that delay the money for months while you fix things under pressure.

What you can fix in four weeks (and what you cannot)

If a round is coming, triage by time-to-fix:

• **Four weeks:** account ownership, access revocation, secrets management, the five core documents, a licence scan of your dependencies, and honest prepared answers to the questions above. This is mostly discipline, not engineering.
• **Two to three months:** a deployment pipeline, meaningful tests on revenue paths, retrospective IP deeds with cooperative former contractors, a basic data map and retention policy.
• **Six months or more:** architectural problems, replacing a single point of failure under load, untangling a hostile IP situation, or reducing dependence on an agency that holds all the knowledge.

The honest move with anything in the third category is to walk into the review with a plan rather than a claim. Reviewers write "known issue, credible remediation plan" in reports all the time. It is one of the better sentences you can earn.

Running the process without a CTO

Plenty of companies reach Series A without a full-time CTO. The review itself is where that gap gets expensive, because someone has to answer the questions in the room, and "I will check with our agency" five times in an hour is its own finding.

This is one of the most common reasons founders bring in a fractional CTO. A few months before the round, they run the internal audit, fix what four weeks can fix, prepare the documentation, and then sit in the review as the credible technical voice. After the round closes, the same person typically helps hire the team the new money pays for.

If the round is closer than that, a single structured day with a senior CTO can at least tell you what the review will find, so nothing in the report surprises you.