Tech Due Diligence Scorecard
Sixteen questions across four dimensions: architecture, code and delivery, team, and security. You get a score out of 32, a bar for each dimension, and a plain read of what the number means for the deal. It runs in your browser: no email gate, and your answers are never sent anywhere.
A technical due diligence scorecard is a fixed set of questions about a target company's technology that turns deal risk into a number instead of an impression from a meeting. This one runs sixteen questions across four dimensions — architecture and scalability, code and delivery, team and key-person risk, security and compliance — for a maximum of 32 points. Oleg Sotnikov, a fractional CTO who runs technical due diligence for funds and acquirers, built it from the checklist he works on live deals. It is a screen that shows where to dig before a full review, and it runs entirely in your browser: no email gate, and your answers are never sent anywhere.
Score the deal
Four dimensions, sixteen questions. Answer for the company as it is today, not for what the roadmap promises.
Answered 0 / 16
Architecture & scalability
01The architecture is documented, and the documentation matches what is actually running.
02The system can carry ten times the current load without a rewrite.
03No critical component is understood by only one person.
04Infrastructure is defined in code and can be rebuilt from it, not clicked together by hand in a console.
Code & delivery
05Automated tests run on every release and can stop it.
06A deploy takes one step, and rolling it back takes one step.
07Dependency and security updates are applied within weeks, not years.
08The team can say which code in the repository was AI-generated and who reviewed it.
Team & key-person risk
09Every critical system has at least two people who can work on it.
10Engineering knowledge is written down, not carried in conversation.
11Departures over the last year did not stall delivery.
12Engineering spend is broken down by system: someone can say what the top three cost to run and maintain.
Security & compliance
13Access is granted by role and revoked when someone leaves.
14Secrets live in a secrets manager, not in the codebase.
15There is a written plan for what happens on a data breach.
16There is a current list of the vendors and the AI models that customer data reaches.
Answer all sixteen questions to see the score.
Scored in your browser with JavaScript. Your answers stay on this page. Nothing is sent to a server, and there is no email gate.
What a scorecard can and cannot tell you
A questionnaire catches what is obviously missing. It cannot check whether the answers are true.
What it can tell you
- Whether the obvious risks are present: no tests, no written architecture, one person holding a system, access nobody revokes.
- Which dimension deserves the review budget, before anyone opens a repository.
- Where the answers get vague. That is usually where the finding is.
What it cannot tell you
- Whether the code does what the demo does. That takes reading it, and reading the tests around it.
- What infrastructure costs at five times the customers. That sits in the architecture, not in anyone's opinion of it.
- Who owns the code. Contractor agreements, open-source licences, and AI-generated code all decide that, and all of it lives in contracts.
A self-assessment is a filter. A due diligence review is evidence: reading the code, the contracts, and the infrastructure, then pricing what it costs to fix what is there.
Frequently Asked Questions
What is a technical due diligence scorecard?
A technical due diligence scorecard is a fixed set of questions applied to a target company's technology so deal risk comes out comparable across deals. This one scores sixteen questions in four dimensions — architecture, code and delivery, team, and security — out of 32 points. The fixed questions are the point: the same ones get asked on every deal, however good the founder is in the room.
When should I run a technical due diligence scorecard?
Three moments earn it. Before a letter of intent, as a cheap screen on whether the deal deserves diligence at all. Before the term sheet, while the price is still being argued and a finding can still move it. And once a year on a company you already own, where a score that drops between years matters more than the number itself.
What does my technical due diligence score mean?
The scorecard runs to 32 points. Twenty-seven and above means no obvious structural risk in the answers given; 17 to 26 means real gaps that belong in the price or in the first hundred days; below 17 means the technology cannot be assumed to carry the plan the price is built on. The bands are cut from the answers you entered, with no benchmark or peer comparison behind them.
Can I do technical due diligence myself?
Partly, and further than most buyers expect. A scorecard and a checklist will surface missing tests, undocumented architecture, and key-person risk without an engineer in the room. What needs a practitioner is judgement on evidence: a healthy coverage number can sit on top of tests that assert nothing, and a flat cloud bill can hide a per-customer cost that inverts at scale.
How long does professional technical due diligence take?
One to two weeks for most software deals, once access to the repository, cloud accounts, and the team is granted. Access usually sets the calendar rather than the review: read-only credentials and interview slots take longer to arrange than the work takes to do. I run these reviews for funds and acquirers, and the deliverable is a written report with the red flags first, risks priced by remediation cost, and a 100-day plan for the quarter after close.
Have the Deal Reviewed Properly
The scorecard tells you where to look. A review opens the repository, the cloud accounts, and the contracts, then comes back with each risk priced by what fixing it costs.
Priced per deal: a day rate or a fixed scope, agreed in writing before any work starts.
Related reading
Deal risk, key-person risk, and the questions that decide a technical review.
