Free tool · No email · Nothing leaves your browser
Technical due diligence scorer
The technical due diligence checklist is not hard to find. Every firm that does this work publishes one, free and ungated, and then keeps the part that matters behind an engagement: the scoring, the ranking, and the report you could actually hand to a board. So the checklist is everywhere and the score is nowhere.
This moves the scoring to the free side. Answer 35 questions and four numbers, and it scores six areas, ranks the findings by how reliably each one gets a deal repriced rather than by generic severity, and gives you a remediation order with rough effort attached. The arithmetic is on the page, the weights are yours to change, and the output copies and prints so it can go to an investor unchanged.
Your answers stay in this browser tab. There is no account, no form, and no server call. Nothing you enter is transmitted anywhere, which is also why nothing is saved: close the tab and it is gone. Copy or print the report before you do.
Overall readiness, out of 100
0 of 35 answered (0%). The 94-point spread is exactly the cost of the 35 unknowns: the low end assumes each turns out badly, the high end assumes each turns out well. Answer them and the range closes.
| Area | Score | Weight | Adds |
|---|---|---|---|
| Key-person risk1 of 5 items answered, 4 unknown | 20–100 | 20% | 4–20 |
| Licensing and the IP chain0 of 6 items answered, 6 unknown | 0–100 | 20% | 0–20 |
| Security and secrets handling0 of 7 items answered, 7 unknown | 0–100 | 18% | 0–18 |
| Deployment and environments1 of 7 items answered, 6 unknown | 7–93 | 16% | 1–15 |
| Code and tests on revenue paths0 of 6 items answered, 6 unknown | 0–100 | 14% | 0–14 |
| Data handling against the published policy0 of 6 items answered, 6 unknown | 0–100 | 12% | 0–12 |
| Overall | sum of the last column | 5–99 | |
Inside an area every item counts the same. A score that quietly weighted its own questions would be the magic number this page exists to refuse. The areas do not count the same as each other, and those weights are in the form on the left.
Findings, ranked by how reliably each reprices a deal
Not by severity, which is what a checklist gives you. The number in the corner is a reprice index from 1 to 10: our judgement of how often this specific finding changes a price or a structure, rather than how bad it sounds. A finding can be embarrassing and score 2.
- Commercial commitmentsreprice index 8/10 · 5–20d
Roadmap commitments already sold to customers but not built.
You answered: 1 committed feature sold and not yet built
What a reviewer concludes. A small forward commitment is normal and is priced as engineering work the buyer inherits, provided it is disclosed rather than discovered. The effort figure is five to twenty engineer-days per committed feature, which is a placeholder until you scope them properly.
Remedy. List them with the contract they were promised in and a realistic date. Disclosed commitments are a schedule; discovered ones are a credibility problem.
- Deployment and environmentsreprice index 5/10 · 2–10d
Unplanned outages in the last twelve months.
You answered: 2 unplanned outages in twelve months
What a reviewer concludes. A normal count for a product under change. What gets assessed is not the number but whether each one has a written cause and a closed action.
Remedy. Group them by cause. Two outages from one unaddressed cause is a much larger finding than four unrelated ones.
Fix these before a data room opens
A different order from the list above, on purpose. That list answers “what is worst”. This one answers “what protects the most price per engineer-day”, which is a different question and usually a different order. The reprice index is divided by the midpoint of the effort band, and the arithmetic is in the last column. The single worst finding is always included even when its ratio is poor, because leaving the biggest item out of a plan makes it a worse plan.
| What to fix | Effort | Reprice ÷ days |
|---|---|---|
| Unplanned outages in the last twelve months.Group them by cause. Two outages from one unaddressed cause is a much larger finding than four unrelated ones. | 2–10d | 5 ÷ 6 = 0.83 |
| Roadmap commitments already sold to customers but not built.List them with the contract they were promised in and a realistic date. Disclosed commitments are a schedule; discovered ones are a credibility problem. | 5–20d | 8 ÷ 12.5 = 0.64 |
| Total for this list | 7–30d |
Engineer-days, not calendar days, and they are our judgement rather than a measurement. Two of them cannot be compressed by adding people: chasing signatures for an assignment agreement and transferring an app store account both run at the speed of someone else’s inbox.
35 questions you have not answered
An unknown is not a pass. A reviewer answers each of these from the repository, the cloud account or the contracts, whether or not you answered it first. Until then each one keeps the range above open by its share of its area’s weight.
- Licensing and the IP chainAre signed IP assignment agreements on file for every contractor and agency who has touched the code?10/10 if it goes badly
- Security and secrets handlingHas there been a security incident involving customer data, disclosed or not?10/10 if it goes badly
- Key-person riskIs any single person the only one who can operate a critical system?9/10 if it goes badly
- Licensing and the IP chainAre employee IP assignment clauses signed and on file for everyone on the engineering team?9/10 if it goes badly
- Data handling against the published policyIs customer data used in any way the published privacy policy does not describe?9/10 if it goes badly
- Key-person riskIf one person left tomorrow, could the company recover every production credential?8/10 if it goes badly
- Licensing and the IP chainIs any GPL or AGPL code linked into the product you ship or host?8/10 if it goes badly
- Licensing and the IP chainIs any code in the product owned by someone other than the company?8/10 if it goes badly
- Security and secrets handlingAre there secrets in the repository history?8/10 if it goes badly
- Deployment and environmentsHave backups been restored, on purpose, in the last twelve months?8/10 if it goes badly
- Key-person riskIs a founder or executive still the primary author of production code?7/10 if it goes badly
- Deployment and environmentsHow does a change reach production?7/10 if it goes badly
- Deployment and environmentsCan you roll back a bad release in under an hour without restoring the database?7/10 if it goes badly
- Code and tests on revenue pathsWhat test coverage sits on the paths that take money?7/10 if it goes badly
- Data handling against the published policyDoes real customer data sit in test environments, analytics exports or on laptops?7/10 if it goes badly
- Data handling against the published policyIs customer data used to train, fine-tune or evaluate a model, and does the policy say so?7/10 if it goes badly
- Licensing and the IP chainAre the domain, trademarks and app store accounts held by the company rather than an individual?6/10 if it goes badly
- Security and secrets handlingIs multi-factor authentication enforced on the code host, the cloud account and the domain registrar?6/10 if it goes badly
- Security and secrets handlingAre production secrets held in a managed secret store rather than in files passed between people?6/10 if it goes badly
- Security and secrets handlingHas production access been reviewed and pruned in the last twelve months?6/10 if it goes badly
- Deployment and environmentsIs infrastructure reproducible from code, or configured by hand?6/10 if it goes badly
- Code and tests on revenue pathsWhat test coverage sits on the paths that write customer data?6/10 if it goes badly
- Data handling against the published policyCan you list every place customer data is stored, including copies and third parties?6/10 if it goes badly
- Data handling against the published policyCan you delete one customer’s data on request, end to end, including backups and analytics?6/10 if it goes badly
- Key-person riskIs there a written escalation path for a production incident that does not name one person?5/10 if it goes badly
- Deployment and environmentsDoes staging match production closely enough to catch a configuration bug?5/10 if it goes badly
- Code and tests on revenue pathsDoes CI block a merge when tests fail?5/10 if it goes badly
- Code and tests on revenue pathsDoes every production change get reviewed by someone other than its author?5/10 if it goes badly
- Licensing and the IP chainHas a dependency licence audit been run, and can you produce the output?4/10 if it goes badly
- Security and secrets handlingIs a dependency vulnerability audit run on a schedule, with someone responsible for the output?4/10 if it goes badly
- Deployment and environmentsDo written postmortems exist for the unplanned outages that happened?4/10 if it goes badly
- Code and tests on revenue pathsCan a new engineer ship something to production in week one?4/10 if it goes badly
- Data handling against the published policyIs the list of subprocessors that touch customer data current and published where it needs to be?4/10 if it goes badly
- Security and secrets handlingHas an external party ever tested the product?3/10 if it goes badly
- Code and tests on revenue pathsDo you know which parts of the codebase are dead?2/10 if it goes badly
What this report is not
A self-assessment records what you believe. A real review reads the repository, the cloud account, the access logs and the contracts, and it regularly finds that a team believed something that stopped being true two years ago. This narrows the gap between what you think a reviewer will find and what they will find. It does not close it, and it cannot, because the closing is done by reading code.
How to read the output, and how people misread it
The overall score is the least useful number on the page. It exists because a single figure is what gets a board to look at the six underneath it. Nothing turns on whether you scored 61 or 68. What turns a deal is one finding with a reprice index of 9 sitting inside an area that scored 80, and that shape is exactly what a summary number hides.
Read the spread first
If the headline is a range, its width is the only thing worth looking at initially. A 30-point spread means you do not know your own systems well enough to be scored, and the fix is an hour with the person who does. Founders read the low end as pessimism. It is not. It is what a reviewer assumes about anything nobody can evidence, because their professional liability requires it.
The matching mistake is answering optimistically to close the range. An untested backup recorded as a working one produces a tidy number and no useful output, and the only person it costs is you, six weeks later, in somebody else’s conference room.
Severity and reprice are not the same axis
Almost every published checklist ranks by severity, which is why they all say the same things in the same order. Severity asks how bad this is for your engineers. Reprice asks how reliably a buyer’s adviser turns it into a number. Those diverge constantly. Dead code is genuinely worse to work in and almost never reaches a valuation conversation. A missing contractor assignment agreement is invisible day to day and can attach an indemnity to your closing documents. That is also why the remediation table sorts differently from the findings list.
The mistakes people make with a number like this
Treating a good score as a verdict. Scoring 85 on a self-assessment means your beliefs are internally consistent, not that they are accurate. The one reliable test is to hand the questions to the engineer who would have to produce the evidence and see which answers change. Two or three usually do, and rarely the ones anyone predicted.
Fixing in checklist order. A checklist is written in the order a reviewer walks through systems, which is not the order you should repair them. Top to bottom means week one on a dependency licence report and week six starting the assignment agreements that need eight weeks of chasing. Start the slow legal items first even though they score lower: they are the only ones with an external clock.
Sending the raw score to an investor. Send the findings and the plan, not the number, which only invites comparison to a benchmark that does not exist. A list of findings you identified yourself, with dates against them, reads as a team that runs its own reviews. The same information delivered as a 63 does not.
Treating the six areas as independent. They compound. Untested code plus manual deployment plus one deployer is not three findings, it is one story about a system that works because a particular person is paying attention. Reviewers write that up as one paragraph and it prices as one paragraph, so fix the cluster rather than the highest single index.
Running it once. The answers move. Run it before you start remediating, keep the report, and run it again a month later. The delta is the only output here a reviewer cannot reproduce by reading your repository. If you inherited the codebase recently and are not sure what any of these answers are, the five signals you can measure in a day is the faster place to start.
When the honest answer is that nothing needs fixing
It happens, and this page says so rather than manufacture a finding to justify itself. Clear every question, leave no unknowns, and the output tells you there is nothing to remediate before a data room opens. It also tells you to be suspicious of that, because the result is uncommon and a self-assessment is a record of belief. Both are true at once. A tool that could only ever produce work for its author would not be worth trusting on the answer where it says there is none.
Keep reading
- Rewrite or refactor: judging a codebase you inheritedFive signals you can measure in a day, from a clean checkout. The fastest way to answer the questions above honestly.
- Switching agencies without losing your codebaseWhere the IP chain and the account ownership questions in this scorer usually go wrong, and how to secure them first.
- Web application developmentWhat we build, what it costs, and the posted bands we work inside. No custom pricing invented for this page.
Other free tools, none of them gated, are on the tools page.
Now fix the top four.
Most of the remediation list is work your own team can do, and this page tells you the order without asking for anything. If the deployment, environment or test-coverage items need hands that are not otherwise busy, send us the report you just copied. Our published bands start at $7,500 and readiness sprints at $6,000. Those are estimates in US dollars, not quotations; the quote that follows scoping is fixed in writing before kickoff.