A Technical Due Diligence Checklist for Founders

What due diligence is really asking

When an investor or acquirer reviews your technology, they want answers to three questions:

1. Is it real? Does the product work the way the pitch says it does?
2. Is it yours? Does the company actually own what it has built?
3. Will it hold? Can the technology and the team support the growth being paid for?

Nobody expects perfect code. They expect you to know where the problems are. A known weakness with a plan is a line in a report. An unpleasant surprise is a reason to reprice the deal.

The checklist

Ownership and legal

• All code lives in repositories the company controls — not a founder's personal account, not an agency's
• Every employee and contractor who wrote code has signed an agreement assigning it to the company
• Open-source licences have been checked; nothing with terms that conflict with how you distribute the product
• Third-party services and APIs are on company accounts, with contracts you can show
• Domains, app store accounts and cloud accounts are in the company's name

Problems in this section are the hardest to fix late. Check it first.

Architecture and scalability

• There is a current diagram of the system, even a simple one
• You can explain what would break first if usage grew tenfold, and roughly what fixing it would involve
• No critical part of the system depends on something unmaintained or about to be discontinued

Code and quality

• Automated tests cover the paths that matter, and they run on every change
• A new developer can get the project running from the documentation
• Dependencies are reasonably up to date, with no known serious vulnerabilities left open

Security and data

• Customer data is encrypted in transit and at rest
• Access to production is limited, and it is removed when people leave
• Secrets are not stored in the code
• You know which data-protection rules apply to you and can show how you meet them
• There is a plan — even a short one — for what happens if there is a breach

Infrastructure and operations

• Deploys are automated and can be rolled back
• Backups exist and have been restored at least once as a test
• Something tells you when the product is down before a customer does
• You know what the infrastructure costs each month and how that changes with growth

Team and process

• The system is not understood by only one person
• Work is tracked somewhere, and changes are reviewed before they are merged
• There is a roadmap, and the team can say what stands in its way

How to prepare

Run your own review first. Go through the list honestly a few months before you expect scrutiny. That leaves time to fix what can be fixed.

Write down what you find. A short document listing known issues and what you intend to do about each is one of the most reassuring things a reviewer can be handed.

Fix ownership problems immediately. Unsigned contractor agreements and personal accounts take time to sort out and can stall a deal.

Do not hide things. Reviewers find them, and what they conclude about your candour matters more than the issue itself.

Getting an outside view

It is difficult to assess a system you built. An independent review before the formal process starts shows you what an investor's reviewer will see, while there is still time to act on it. That is something we do as part of technical consulting — and if you want to know what such a review examines in the code itself, see what a code audit actually covers.