Free Tool
Technical Due Diligence Checklist
The questions we ask before touching an inherited codebase.
Use it before an acquisition, before taking over a vendor’s work, or on your own system to find out what you actually have.
Work through the checklist
Nothing is stored or sent anywhere — the ticks live in this browser tab only. Anything you cannot answer is itself a finding worth recording.
0 of 48 checked
Code and build
Architecture and data
Security and data protection
Testing and quality
Delivery and operations
Team and knowledge risk
Quick Answer
Updated August 22, 2026
What should a technical due diligence cover?
Six areas: whether the code builds reproducibly and is understandable, whether the architecture will survive growth, security and data handling, delivery process and deployment, dependency and licence health, and team and knowledge risk. The single most revealing check is the first one — can a new engineer clone the repository and get it running from the README alone. A surprising share of production systems fail that, and everything else is harder to assess until they pass.
Checks
48 across 6 areas
Typical audit
1 – 3 weeks
Most revealing
Does it build from the README?
Best for
- Acquirers assessing a target’s engineering
- Companies taking over a codebase from a departing vendor
- CTOs auditing a system they inherited internally
Not best for
- A substitute for a security penetration test
- Legal or financial due diligence
- Assessing a system nobody will give you access to
FAQ
Questions about this tool
How long does technical due diligence take?
One to three weeks for a mid-sized codebase, depending on access and size. The first few days are usually spent getting the system running, which is itself one of the most informative parts of the exercise.
What is the biggest red flag?
A build that only works on one person’s machine. It usually means undocumented environment assumptions, and it makes every other assessment slower and less reliable. Committed secrets in git history are a close second.
Do we need this before an acquisition?
Yes, and it is cheap relative to the transaction. The cost of discovering after close that a system needs rebuilding is orders of magnitude larger than an audit.
Can we do this ourselves?
Much of it, if you have a senior engineer with time. The part that benefits from an outsider is judgment about severity — deciding which findings are genuinely dangerous rather than merely untidy is where experience matters.
Does this replace a penetration test?
No. This assesses whether security practices exist; a penetration test attempts to break the running system. They answer different questions and a serious assessment uses both.
Related
Go from a number to a plan
The guides behind this tool, and the other free tools alongside it.