Technical due diligence checklist

Due diligence is rarely where a deal is won. It is often where one slows down, shrinks or quietly dies. The questions are predictable, so the best time to answer them is months before anyone asks. Work through each area below, gather the evidence, and be honest about the gaps. A gap with a dated plan reads as a well-run company. A gap discovered by the investor reads as a risk.

Architecture

The investor wants to know whether the system makes sense, and whether anyone other than its original author understands it.

• A current diagram. One page that shows the main parts of the system, where the data lives and what talks to what. If it is more than six months old, it is probably wrong.
• More than one person who can explain it. If only one developer can walk through the architecture, that is a finding, and it links straight to key-person risk.
• Single points of failure. Name the components that would take the product down if they failed, and what happens when each one does. "We would restore from backup" is only an answer if someone has tested the restore.
• Third-party dependencies. List the services the product relies on, from hosting and payments to email and analytics, and what each one is used for.
• Separate environments. Test and live should be kept apart, with real customer data kept out of test.

Nobody expects a startup to have perfect architecture. They expect you to know where the weak points are.

Code quality

Reviewers are not grading your code for style. They are asking how risky it is to change.

• Everything in version control, in accounts the company owns. Code on a contractor's personal account is a problem waiting to happen.
• Automated tests that run on every change, and an honest view of what they cover.
• Review before release. Every change to production should have been seen by a second person.
• A clear path to production. How changes are released, how often, and how a bad release is rolled back.
• Technical debt written down. Every product has debt. A written list with a plan shows you are managing it. Debt the investor finds for you looks like debt you did not know about.
• Onboarding time. How long a new developer takes to ship their first change is a good proxy for how understandable the codebase is.

Security

Security questions in due diligence are about whether a breach could damage the value of what they are buying.

• Who has access to production systems and data, and whether that list is reviewed.
• Leavers. Access should be removed promptly when people leave. Have a recent example ready.
• Multi-factor authentication on admin, email and cloud accounts.
• Incidents. What has happened, how it was handled and what changed afterwards. "None" is only credible if you have a way of detecting them.
• Updates. How dependencies and systems are kept patched.
• Certificates and testing. Which certifications you hold, such as Cyber Essentials or ISO 27001 for startups, and the date of your last independent penetration test, with what was fixed.

IP ownership

This is the area most likely to surprise a founder, and the one investors take most seriously, because it decides whether the company owns what it is selling.

In UK law, a computer program is protected by copyright as a literary work (section 3 (opens in a new tab)). The author of a work is its first owner, with one main exception: work made by an employee in the course of their employment belongs to the employer, unless they agree otherwise. Work written by a contractor, a freelancer or an agency is not covered by that exception, so it stays with them unless they assign it to you. An assignment of copyright is not effective unless it is in writing and signed by or on behalf of the person assigning it.

Source: Copyright, Designs and Patents Act 1988, section 11 (opens in a new tab), correct as of 5 October 2026. Source: Copyright, Designs and Patents Act 1988, section 90 (opens in a new tab), correct as of 5 October 2026.

In practice, that means:

• Employment contracts that make ownership of work clear.
• Signed contracts with every contractor and agency that wrote code, assigning the IP to the company. Check the early days too: the freelancer who built the first version is easy to miss.
• Open source licences. Every library you use comes with a licence, and licences have terms. A licence report for all dependencies lets a lawyer confirm none of them creates obligations you have not met.
• Accounts in the company's name. Domains, code repositories, cloud accounts and app store listings should belong to the company, not to a founder or a supplier.

Take legal advice on anything unusual. A gap here is fixable before a deal, and much harder to fix during one.

Team and key-person risk

An investor is buying a team as much as a product. The question is what happens if one person walks out.

• The person who knows the system best. If they left tomorrow, what would break, and who would fix it?
• Documentation good enough for a new team. Runbooks for the routine jobs and the emergencies, and enough written down that the product could be handed over.
• Who is in the team, and on what terms. Employees, contractors and agencies, with their roles and notice periods.
• The hiring plan. If the roadmap depends on hires you have not made, say so and show the plan.

Small teams always carry some key-person risk. What reassures an investor is that you have seen it and reduced it.

Scalability

The investment case usually assumes growth. This area asks whether the technology can carry it, and at what cost.

• What breaks first at ten times today's load. Show load test results or a reasoned capacity analysis, not a guess.
• Monitoring and alerting on the live system, so problems are found by you rather than by customers.
• Backups that have been restored. A backup that has never been restored is a hope, not a plan. Record the date of your last restore test.
• Uptime history against any service level you have promised customers.

When I rebuilt a legacy platform as a cloud-native SaaS, moving from a licensed system on VPS hosting to AWS, infrastructure costs fell by 96% and the platform ran for three years with zero downtime. Capacity matters, but so does what each extra unit of capacity costs.

Costs

Investors want to know how the cost of the technology behaves as the business grows.

• The monthly run cost: hosting, licences and tools, backed by invoices.
• How costs grow with customers or usage. A cost per customer or per transaction, tracked over time, shows whether margins improve or erode as you scale.
• Contracts with minimum terms or exit costs, and when they renew.
• Next year's planned technology spend, linked to the roadmap.

Surprises here change valuations. Know your numbers before the investor works them out.

Compliance

The last area checks that the company handles data lawfully and can prove its policies are real.

• A data map. Where personal data lives, why you hold it and which suppliers process it.
• Written contracts with processors. Under UK GDPR, whenever a controller uses a processor, the processing must be governed by a binding contract. Expect to show signed data processing agreements with your key suppliers.
• A privacy notice that matches what the product does.
• Sector rules. Any regulation specific to your market, and how you meet it.
• Evidence that policies are followed: audit records, training logs and review notes, not only the policy documents.

Source: ICO, when is a contract needed and why is it important? (opens in a new tab), correct as of 5 October 2026.

Getting ready before the investor asks

Work through the spreadsheet one area at a time and mark each question Ready, In progress or Gap. For every gap, write who will fix it and by when. Then fix the IP and access questions first: they are the cheapest to solve and the most damaging to leave.

This is part of the work I do as a fractional CTO preparing a company for investment: making sure the answers are true, the evidence exists and the gaps are closed before anyone else finds them.