Technical due diligence answers one question. Will this technology support the business the investor is being asked to fund, and what will it cost to get there. The checklist below is the one I use, whether I am running diligence for an investor or preparing a founder to face it. Founders, work through it before the raise and you will find the problems before the investor does. Investors, if a founder cannot answer most of this, that is the finding.
Each section ends with what a strong answer looks like and the red flag that most often sinks a deal.
Architecture and scalability
- A clear, current diagram of the system and how the parts connect
- What breaks first at 10 times the current load, and whether anyone knows
- Hosting, environments and how changes reach production
- Single points of failure, in the system and in the people who understand it
- How much of the stack is standard and supported, and how much is bespoke and fragile
- The last time the system fell over, why, and what changed afterwards
A strong answer. A one-page diagram that matches reality, a named bottleneck with a plan, and an incident history that shows learning.
The red flag. Nobody can draw it. If the architecture lives only in the head of one engineer, the diligence has already found its first key-person risk.
Code and engineering practice
- Version control, with a sensible branching and review process actually in use
- Automated tests, how much they cover, and whether they run before every release
- How often releases happen and how often they fail or roll back
- The known technical debt, written down, with an honest view of what it will cost to fix
- Dependencies that are out of date, unsupported or carry known vulnerabilities
- Documentation good enough for a new senior engineer to become productive in a fortnight
A strong answer. Releases weekly or better, a test suite that catches real problems, a debt register with estimates, and a repository a new hire could find their way around.
The red flag. Releases are rare, large and frightening. That usually means no tests, no review and a team that has learned to be afraid of its own system.
Security and data
- Who can access what, and how that is granted and removed
- Where personal data lives, how it is protected, and whether a data protection impact assessment exists where one should
- Backups, and the date they were last tested by actually restoring one
- Secrets and credentials, where they are stored, and whether any are in the code
- Any certification held, such as Cyber Essentials or ISO 27001, and when it expires
- Any incidents or breaches, and what changed afterwards
- How the business would respond to a breach tomorrow, and who would lead it
A strong answer. An access list that matches the staff list, a restore test within the last quarter, secrets in a vault, a current certificate, and an incident plan someone can describe.
The red flag. A backup that has never been restored. It is the single most common finding, it is cheap to fix, and it tells the investor the business has never asked itself what happens when things go wrong.
Intellectual property and licensing
- Who wrote the code, and whether every contractor and agency assigned IP in writing
- Open-source licences in use, and whether any would force disclosure or restrict commercial use
- Third-party services the product depends on, and the terms that govern them
- Domain names, trademarks and key accounts, all owned by the company rather than an individual
- Any code or data brought in from a previous employer or a university
A strong answer. Signed assignments on file for everyone who ever touched the code, a licence scan with no surprises, and every account in the company’s name.
The red flag. An early contractor who built the core and never signed anything. It surfaces in almost every third diligence, and it can stop a deal cold until it is resolved.
People and process
- Who the key technical people are, and what happens if any of them leave next month
- How work is prioritised, planned and tracked, and whether the roadmap is credible against the team’s actual pace
- The relationship with any agency or offshore team, the contract, and the quality of what they deliver
- Team structure, who reports to whom, and whether there is senior technical leadership
- Hiring, how long roles take to fill and how many have been filled in the last year
- Retention, who has left and why
A strong answer. More than one person who understands each critical part, a roadmap that matches the delivery history, and a team that has been stable.
The red flag. One developer who knows everything, no senior technical leader, and a roadmap that promises in six months what the history says takes eighteen.
Cost and plan
- The current technology run cost, broken down, and the trend
- What the funding will be spent on technically, and whether the plan matches the team’s capacity
- The honest statement of what the product cannot do today that the business plan assumes it can
- The cost of paying down the known technical debt, and when it is scheduled
- Supplier and licence commitments the business is locked into
A strong answer. A run cost the founder can explain line by line, a spending plan that names the hires and the dates, and a clear list of what the product does not yet do.
The red flag. A business plan that assumes capability the product does not have, with no line in the budget to build it.
How to use this
Founders, answer every line in writing before the deck goes out. Where the answer is weak, fix it or own it with a dated plan. Investors forgive known debt with a plan. They walk away from surprises. Our piece on a fractional CTO when you are raising investment covers how to prepare, and the fuller explainer on technology due diligence sets out when a board should commission it.
Investors, weight the people and process sections more than the code. A good team with messy code fixes the code. A weak team with clean code does not stay clean. And ask for the restore test and the IP assignments on day one, because they are the two findings most likely to change the price.
For private equity investors reviewing a portfolio company rather than a new deal, the checklist is the same but the emphasis shifts towards cost, capacity and exit readiness. Our piece on technology due diligence for private equity portfolio companies covers that.
What a diligence report should contain
A one-page summary with the three or four findings that matter and a view on whether the technology supports the plan. A section per area above, with the evidence and a rating. A costed list of the fixes, split into before close, first 90 days and first year. And a plain statement of what the reviewer could not verify and why.
A report that runs to 60 pages with no summary is a report nobody will read. A report that only lists problems with no costs is a report nobody can act on.
Frequently asked questions
What does technical due diligence cover?
Architecture and scalability, code and engineering practice, security and data, intellectual property and licensing, people and process, and cost and plan. The common failures are untested backups, unassigned IP and key-person risk.
How long does technical due diligence take?
Usually one to three weeks for a growing business, depending on access and how well documented things are. Well-prepared founders shorten it considerably.
Can a founder run technical due diligence on themselves?
Yes, and they should, ideally with an independent senior technologist asking the questions. A technology review run against this checklist is the practical version.
What is the most common red flag?
A business that cannot say who owns its code, or that has never restored a backup. Both are cheap to fix and expensive to be caught with.
Should investors weight code quality or team quality more?
Team and process. A strong team with messy code fixes the code. A weak team with clean code lets it decay. The people sections predict the next two years better than the code sections.
What should a diligence report look like?
A one-page summary of the findings that matter, a rated section per area with evidence, a costed fix list split by timing, and a clear note of what could not be verified.