The technical due diligence checklist
61 items across 12 areas, in two modes. A founder preparing works the list as the questions they are about to be asked. An investor reviewing works it as what they would otherwise be taking on trust. Every item carries what would actually settle it, which is the part most checklists leave out. It runs in your browser and nothing is sent anywhere.
The same list an investor works from, phrased as the question you will be asked. An honest not sure here is worth more than a confident yes, because the not sure is the one you still have time to fix.
Access and authorisation
Who can reach what, and whether the answer is enforced somewhere the caller cannot edit.
Data and privacy
What is stored, where it is, and what happens to it when somebody asks for it back.
Secrets and configuration
What the deployment hands out to anybody who asks for it.
Dependencies and supply chain
What you ship that somebody else wrote.
Reliability and recovery
What happens on the day something breaks.
Performance and cost
What happens when there is ten times as much of everything.
Engineering practice
How changes get made, and what stops a bad one.
Architecture and documentation
Whether somebody who was not there could work out how this fits together.
Team and commercial
The part of technical diligence that is not about the software.
AI and model exposure
The questions that did not exist three years ago, and that now decide whether a roadmap is real.
Ownership and IP
Whether the company actually owns what it is selling.
Roadmap credibility
Whether the plan and the engineering reality are the same document.
What this list is made of
Every item is labelled by what could settle it, read from the controls in the active pack rather than decided here. Which is how 41 of 61 come out as questions no control covers: a number worth seeing before you start, and one we would rather show than round.
Answer some of the list above and the open items will be gathered here, separated by what it would take to close each one.
How each item is labelled
A checklist that treats every item as equally answerable is comfortable and wrong. Whether your dependencies carry a known advisory is a question a machine settles in seconds. Whether one person leaving would stop the product is not a question a machine should be allowed near.
So each item names the controls in the active control pack that bear on it, and the label is read from those controls rather than decided here. An item whose control puts the system under test is labelled independently tested. One whose control reads the source, the configuration or a query plan is labelled evidence collected, because finding that a check exists is a narrower claim than watching it hold. An item with no control behind it is labelled human diligence.
41 of the 61 items fall in that last group. That is not a gap waiting to be closed by better software. Contracts, people and judgement are diligence, and they need a person.
What this checklist is not
It is not due diligence. Answering a list of questions about your own software produces a record of what you believe, and belief is where diligence starts rather than where it ends. The value is in finding your own gaps early, while there is still time to do something about them.
It is also not a scoring tool. There is no grade at the end, because a score built out of self-reported answers would be a number with nothing behind it, and reporting one would undercut the entire point of the labels.
Common questions
What should a technical due diligence checklist include?
At minimum: access and authorisation, data and privacy, secrets and configuration, dependencies and supply chain, reliability and recovery, performance and cost, engineering practice, architecture and documentation, and the team and commercial questions that are not about software at all. This checklist covers 61 items across those 12 areas, and labels each one with what would actually settle it.
What is the difference between founder mode and investor mode?
The list is the same. The phrasing is not. Founder mode asks whether you can answer the question when it arrives; investor mode asks what you would be taking on trust if you did not check. Working both is useful: the items where the two phrasings feel different are usually the ones where a founder's yes and an investor's verified are not the same claim.
Does completing this checklist mean the diligence is done?
No, and it is worth being blunt about it. A completed checklist records what you believe about your own system. It is a way to find your own gaps before somebody else does. Every answer in it is self-reported, which is the part any serious reviewer will discount, and reasonably so.
How do you decide what StackAttest can verify?
Each item names the controls in the active SA-CORE pack that bear on it, and the label comes from those controls' own verification methods. 20 of the 61 items have at least one control behind them. The other 41 have none and are labelled human diligence, because contracts, people and judgement do not have a control and a tool that pretended otherwise would be selling a number rather than an answer.
What does the evidence grade on an item mean?
It is the minimum grade the pack will accept as a pass for the controls behind that item, so it tells you how strong an answer has to be before it counts. It describes the Standard rather than any particular validation, and no grade appears on an item that no control covers.
Is this free, and does anything get sent anywhere?
It is free, needs no account, and runs entirely in your browser. Your answers stay on your machine, nothing is stored, and nothing is sent to StackAttest or anyone else. Closing the tab clears it.
When a checklist stops being enough
The moment somebody else has to believe the answers. A technical due diligence validation produces the same answers with evidence attached and a grade on each one, which is what makes them reviewable by somebody with no reason to take your word for anything.
If you want something back in the next minute instead, the free AI app security check tests a deployed application from outside with no account, and reports the controls a public URL cannot reach as uncovered rather than passing them.