RESOURCES · FIELD GUIDE · UPDATED JULY 2026

Technical due diligence checklist for software companies

A working guide to assessing product, codebase, delivery, team, and operational risk before money or major commitments move. What to inspect, what evidence to request, which questions to ask, and which red flags should change the decision.

Use the checklist Download the PDF ↓

6 SECTIONS · NO SIGN-IN · WORKS IN PRINT

00 — WHAT THIS REVIEW IS FOR

Technical diligence answers one question: can this software, this team, and this way of working carry the plan being priced?

For investors and acquirers, it surfaces what the pitch can't: hidden delivery risk, fragile architecture, single points of failure, security exposure, and roadmaps the team cannot actually ship.

For boards, it converts "engineering says it's fine" into evidence a non-technical director can weigh.

For founders, running it on your own company before a raise or sale means you find the problems before the other side's advisor does.

This is not legal, financial, or compliance certification. It tells you where technical risk lives and how much of it should move the price. It does not replace counsel, audit, or a SOC 2 report.

The checklist.

SIX SECTIONS · WORK IN ORDER

Each section lists what to inspect, the evidence to request before you accept an answer, the questions that separate rehearsed responses from real ones, and the red flags that should change the decision, not just the notes.

Product, roadmap, and technical strategy

Whether what's being built matches what's being sold, and whether the roadmap is a plan or a wish.

WHAT TO INSPECT

The live product against the pitch deck: which flagship claims are shipped, partial, or aspirational
The roadmap's dependency chain: what must be true (hires, rewrites, integrations) for each milestone
How technical strategy decisions get made and recorded, and by whom
The gap between the demo environment and what paying customers actually run

EVIDENCE TO REQUEST

Current roadmap with owner and status per item
Last two quarters of planned-vs-shipped
Any written architecture or technical strategy docs
Feature flags / entitlements config for the demoed features

QUESTIONS TO ASK

Which roadmap item are you least confident about, and why?
What did you plan to ship last quarter that didn't ship?
Who can say no to a technically risky commitment made in a sales call?

RED FLAGS: SHOULD CHANGE THE DECISION

Flagship demo features are hardcoded or run on mock data
The roadmap has no owners, no dates, and no relation to team capacity
Strategy lives entirely in the founder's head, with nothing written down

Architecture, codebase, and dependencies

Whether the system can carry the plan being priced, and how much of it is understood by more than one person.

WHAT TO INSPECT

System architecture end to end: data flow, service boundaries, integration points, and where state lives
Codebase health signals: test coverage, module coupling, dead code, consistency across the repo
Third-party and open-source dependencies: licenses, maintenance status, upgrade lag, single-vendor exposure
The hardest scaling constraint: the query, queue, or component that breaks first at 10x load

EVIDENCE TO REQUEST

Repository access (read-only), not a guided tour
Dependency manifest with versions and license report
An architecture diagram dated within the last year
The last major refactor's before/after rationale

QUESTIONS TO ASK

What part of the codebase would you rewrite if you had a quarter?
What happens at 10x current load, and what fails first specifically?
Which dependency would hurt most if it were abandoned tomorrow?

RED FLAGS: SHOULD CHANGE THE DECISION

Access to the code is refused or only offered as a screen-share tour
A core component is on an EOL runtime or an abandoned framework
Copyleft-licensed code inside the proprietary core product

Reliability, security, and data handling

Whether the company can survive its worst day: an outage, a breach, or a deletion request it can't fulfil.

WHAT TO INSPECT

Incident history: frequency, duration, root causes, and whether postmortems changed anything
Access control reality: who can reach production, customer data, and secrets, and how that's revoked
Backup and restore: not whether backups exist, but when a restore was last actually tested
Personal-data flows: what's collected, where it's stored, who it's shared with, and how deletion works

EVIDENCE TO REQUEST

Last 12 months of incident reports and uptime data
Most recent penetration test or security review, with remediation status
Access-control matrix for production systems
Data-processing inventory or records of processing

QUESTIONS TO ASK

Walk me through your last serious incident, start to finish.
When did you last restore from backup, and how long did it take?
If a customer demanded full deletion today, could you prove completion?

RED FLAGS: SHOULD CHANGE THE DECISION

Production credentials shared in chat, or ex-employees with live access
Backups exist but a restore has never been rehearsed
No one can enumerate where customer personal data actually lives

Delivery process and technical debt

Whether shipping is a repeatable system or a heroic act, and how much drag the debt already adds.

WHAT TO INSPECT

The path from idea to production: planning, review, testing, deploy, rollback, as practiced, not as documented
Cycle time and deploy frequency over the last two quarters, and their trend
The debt register (or its absence): what's known, what's measured, what's ignored
How quality is enforced: review standards, CI gates, and what happens when someone bypasses them

EVIDENCE TO REQUEST

Deploy log or release history for the last quarter
CI configuration and recent pipeline pass rates
Any existing technical debt inventory or audit
Three recent pull requests, chosen by you, not by them

QUESTIONS TO ASK

How long does a one-line fix take to reach production?
What do you do when the release is late: cut scope, slip, or skip tests?
Where does the team lose the most time each week?

RED FLAGS: SHOULD CHANGE THE DECISION

Deploys are rare, manual, feared, or only one person can do them
Estimates are systematically doubled and still missed
Debt is acknowledged verbally but appears nowhere in planning

Engineering team, ownership, and leadership

Whether the knowledge, judgment, and momentum survive the departure of any one person, including the founder.

WHAT TO INSPECT

Key-person concentration: which systems only one person can safely change
The real org chart: who decides, who reviews, who mentors, versus the titles
Retention and hiring: tenure distribution, recent departures and why, offer-acceptance rate
Leadership depth: what decisions the team makes well without the founder in the room

EVIDENCE TO REQUEST

Team roster with tenure, role, and system ownership
Contributor concentration per critical repo (commit history)
Departure list for the last 18 months with reasons
Compensation bands versus market for key retained people

QUESTIONS TO ASK

If your most senior engineer left Friday, what breaks first?
Who made the last major architecture decision, and who disagreed?
Which engineers must stay for this plan to work, and do they know?

RED FLAGS: SHOULD CHANGE THE DECISION

One person owns the core system and has no documented successor
Senior departures cluster in the last six months
The founder reviews every meaningful change personally

Cost, infrastructure, and operational resilience

Whether unit economics survive growth, and whether the infrastructure is an asset or a liability at scale.

WHAT TO INSPECT

Infrastructure cost per customer/tenant and its trend as usage grows
Environment parity and reproducibility: can production be rebuilt from code, or only from memory
Vendor and platform lock-in: what a forced migration would actually cost
Operational load: on-call burden, manual toil, and what breaks during vacations

EVIDENCE TO REQUEST

Last 6 months of cloud/infrastructure bills, itemized
Infrastructure-as-code coverage (what's codified vs hand-built)
Disaster-recovery plan and the date it was last exercised
Contract terms for critical vendors (data egress, termination)

QUESTIONS TO ASK

What does one additional enterprise customer cost to serve?
If your cloud account vanished, how long to rebuild from code?
Which manual task would hurt most if the person doing it left?

RED FLAGS: SHOULD CHANGE THE DECISION

Infrastructure cost grows faster than revenue with no plan to bend it
Production was built by hand and no one is sure it can be rebuilt
A single vendor could impose a forced migration the team can't fund

What a useful diligence output looks like.

07 — THE DELIVERABLE

A pile of notes is not diligence. Whatever the format, the output should let a decision-maker act on it in one sitting:

Risk map

Every material risk rated by likelihood and business impact, and whether it should affect price, terms, or the post-close plan.

Evidence log

What was actually reviewed versus what was claimed in interviews, so every conclusion is traceable to something inspected.

Architecture assessment

Whether the system can carry the plan being priced, with the specific limits (scale, security, coupling) that will bind first.

Delivery constraints

The honest shipping capacity of the team as it exists, and what the roadmap assumes that the process can't yet support.

Prioritized recommendations

Not a wish list: the ordered set of actions that reduce the most risk per unit of effort, written so the team can start Monday.

08 — WHEN A CHECKLIST ISN'T ENOUGH

A checklist finds the questions. It doesn't weigh the answers.

If the decision is large, contested, or on a deal timeline, or the answers you're getting are fluent but unverifiable, that's when an independent technical read earns its cost. Someone who has operated these systems can tell the difference between a scary-looking codebase that's fine and a clean-looking one that isn't.

How I run these reviews: technical due diligence on the expertise page
What the work looks like: case studies with challenge and result
On a deal timeline: book a call directly below

09 — TAKE IT WITH YOU

Bring this into the decision meeting.

Take the PDF for the data room, or bring the deal itself. Twenty-five minutes on what you're evaluating, and whether an independent read would change the answer.

Download the PDF ↓

FREE · NO PITCH · REPLIES WITHIN ONE BUSINESS DAY