Technical Due Diligence Checklist
This is the working checklist behind my due diligence engagements, published in full: 44 items across eight categories, in the order I go through them on a live deal. No form, no email, no gated PDF. Copy it into your own template and screen your next deal yourself.
A technical due diligence checklist is the structured list of questions an investor or acquirer works through to judge a target's software, infrastructure, and engineering team before a deal closes. The checklist below is the one Oleg Sotnikov works through on live diligence engagements: 44 checkable items across eight categories, covering architecture and scalability, code quality and AI-code provenance, team and bus factor, security and compliance, infrastructure and cost trajectory, data and IP, product and delivery metrics, and operations. It is published in full on this page, with no email gate, so a deal team can run a first-pass screen without hiring anyone.
How to Use It
Scope it to the deal
A minority round into a Series A and a full acquisition need different depth. Mark the categories that decide your deal (usually team risk and cost trajectory for growth investments, IP and security for acquisitions) and go deep there first. The rest still gets a pass, just a faster one.
Walk it with evidence
Go through the marked categories with the engineers who built the system, not only the CTO. Ask for the artifact behind every answer: the billing export, the commit graph, the postmortem, the license scan. Most serious findings start as a gap between what the documentation claims and what the repository shows.
Weigh findings by deal impact
Sort the reds by what fixing them costs in money and months, then decide which ones move the price, which ones become closing conditions, and which ones are simply work for the first quarter after close. A long list of small findings is not the same risk as one item that stalls the roadmap.
The Checklist
Score each item red, yellow, or green. Green means you saw the evidence. Yellow means you got an answer with no artifact behind it. Red means the answer itself is the problem. Anything still yellow when the process ends belongs in the report as an open risk. What a founder tells you is a data point, not proof.
Architecture and scalability
- Get an architecture diagram drawn by an engineer who works on the system, not the one from the sales deck.
- Find the single points of failure (one database, one queue, one region) and ask what happens when each goes down.
- Trace the busiest read path end to end and price it at 10× today's traffic.
- Check whether the data model carries the product plan, or whether the next feature needs a migration nobody has scoped.
- Look for state hidden on individual machines: local disk, in-process caches, cron jobs on a hand-configured server.
- Ask which architectural decision the team regrets and why they have not undone it.
Code quality and AI-code provenance
- Measure test coverage on the paths that carry money, not the repo-wide average.
- Ask what share of the codebase an LLM wrote, then check the answer against commit sizes and timestamps.
- Pick the three most AI-heavy files and have an engineer explain them line by line.
- Check whether AI-generated code is covered by tests the team wrote or by tests the same model produced.
- Read the last thirty pull requests: review depth, time to merge, who approves whom.
- Count dead code, duplicated modules, and TODOs older than a year. They show how the team handles debt.
Team and bus factor
- Map commit history against the org chart and find every component with one contributor.
- Name the two people whose resignation would stall the roadmap for a quarter.
- Check retention offers, notice periods, and vesting dates against the expected close date.
- Ask who is on call, how often, and how the rotation on paper compares with the pager logs.
- Find out how long onboarding takes for a new engineer, measured to their first production deploy.
Security and compliance
- Scan the repository history for secrets, then confirm the exposed ones were rotated.
- Review who holds production access, when it was last audited, and how offboarding revokes it.
- List known CVEs in the dependency tree and how long the oldest critical one has been open.
- Ask for the last penetration test report and the fixes that followed it, not just the certificate.
- Where SOC 2, GDPR, or HIPAA is claimed, separate the controls already implemented from the ones on a roadmap slide.
- For AI features, establish which customer data reaches which model provider and what that provider retains.
Infrastructure and cost trajectory
- Pull twelve months of cloud bills and plot the curve against revenue and usage.
- Separate fixed platform cost from per-customer cost, then recompute margin at the volumes in the deal model.
- Check LLM token spend per active user and what it does when the plan's growth arrives.
- Find the infrastructure nobody can account for: orphaned environments, forgotten snapshots, idle clusters.
- Confirm the setup is reproducible from code rather than living only in a console someone configured by hand.
Data, IP, and licensing
- Confirm the company owns every line: employees, contractors, agencies, and departed founders.
- Match the IP assignment paperwork against the names in the git history.
- Run a license scan and flag copyleft obligations in anything shipped to customers.
- Establish what rights the company holds to the data it trains or fine-tunes on.
- Check that the model provider's terms permit the commercial use the product depends on.
Product and delivery metrics
- Take deploy frequency and lead time from commit to production out of the pipeline, not out of memory.
- Look at the change failure rate and how often a release gets rolled back.
- Compare what shipped in the last two quarters against the roadmap that was promised.
- Track the bug backlog over twelve months: opened against closed.
- Ask what the team shipped that customers never used, and how they found out.
Operations and incident history
- Read every postmortem from the last twelve months, and ask why the missing months have none.
- Compare real uptime against the SLA the customer contracts promise.
- Verify backups exist and that somebody has restored from them recently.
- Ask for mean time to detect, not only mean time to recover.
- Establish who gets paged at 3am and whether that person is staying after the deal.
- Check monitoring coverage: which failures the team learns about from dashboards and which from customers.
Frequently Asked Questions
What does technical due diligence cover?
Technical due diligence covers architecture and scalability, code quality and how much of the codebase an LLM wrote, the engineering team and its key-person risk, security and compliance, infrastructure and cost trajectory, data and IP ownership, product delivery metrics, and operational history. Underneath all of it sits one question: whether the technology can carry the plan the deal is priced on, and what it costs to fix the parts that cannot. Each finding should come back with the evidence attached and an estimate of the remediation effort.
Who should run technical due diligence?
Someone who has built and operated systems at the scale the target claims, rather than a consultant filling in a form. The value sits in the follow-up question: knowing that a clean coverage number can sit on top of tests that assert nothing, or that a flat cloud bill can hide a per-customer cost that inverts at 5×. Worked by a practitioner, this checklist produces findings; worked by a form-filler, it produces a document.
What are the biggest red flags in technical due diligence?
Three come up more than the rest. A bus factor of one, where a single engineer is the only person who understands a system the business runs on. AI-generated code with no tests around it and nobody on staff who can explain what it does. And infrastructure spend nobody can account for: a bill growing faster than usage, with orphaned environments and no owner. Each is fixable, and each costs real money and months, which belongs in the price.
When in the deal should technical due diligence happen?
After the term sheet or letter of intent, and before the investment committee or board signs off. Earlier usually means access the target is not ready to grant; later means findings land after the price is fixed, with nothing left to negotiate with. Two to three weeks before the decision date is the usual window, which fits a one-to-two-week review with room for follow-ups. A first-pass screen with this checklist can happen far earlier, and that is what it is for.
Have It Run on Your Deal
The same checklist, worked by the person who wrote it. One to two weeks, a written report with the red flags first, and a 100-day plan for the quarter after close.
Priced per deal: a day rate or a fixed scope, agreed in writing before any work starts.
Related reading
Deal risk, team risk, and what AI-written code leaves behind in a codebase.
