The technical due diligence checklist.
What an independent reviewer actually examines before a transaction, in the order it pays to examine it. Use it to prepare a deal, to brief a reviewer, or to test whether the diligence you are being offered covers what matters.
This page prints cleanly, without the navigation. No signup, no download gate.
Before the data room opens.
- State what is actually being bought
- Product, team, contracts, data, or code: the weight of every later finding depends on which of these carries the price.
- Write down the plan the deal assumes
- Scale it, integrate it, or hold it. A system can pass for one plan and fail for another.
- Name the questions that would kill the deal
- Agree them with the deal team first; diligence that examines everything ranks nothing.
- Secure real access
- Repository, cloud accounts, issue tracker, and the people who ship. Documents describe intent; access shows reality.
The system as it is, not as drawn.
- Compare the architecture diagram with actual dependencies
- The gap between the two is a finding in itself.
- Find the boundaries that transmit change
- Coupling is where integration cost and delivery risk hide.
- Read the code where change happens
- Quality in the hotspots matters; quality in dormant corners does not.
- Check tests where failures are expensive
- Coverage numbers mean little; tests around the money paths mean a lot.
- Trace the provenance of recent code
- Generated code is not a defect, but unreviewed generated code in core paths is an exposure the buyer inherits.
- Audit licences and repository history
- Copyleft in the core and secrets in the history are classic post-closing bills.
Whether the team can carry the plan.
- Watch how a change actually ships
- Cadence, review, and rollback tell more than any process document.
- Map the knowledge to the people
- What leaves when one person leaves is key-person risk, priced or not.
- Test whether documentation survives departures
- Ask for the runbook, then ask someone junior to follow it.
- Weigh the roadmap against the run rate
- A roadmap the current team cannot staff is a valuation input.
What production says about the system.
- Read the incident history for classes, not counts
- Repeated incidents of one class point at a structural cause.
- Check that someone can see the system
- Observability gaps turn small failures into long outages.
- Verify recovery, not backups
- A backup that has never been restored is a hope, not a control.
- Compare capacity headroom with the deal plan
- The growth case must fit inside what the platform can actually carry.
Security and the bills that arrive later.
- Walk the attack surface
- Public endpoints, third-party integrations, and the paths between them.
- Age the dependency tree
- Abandoned dependencies in critical paths are unfunded liabilities.
- Test access control against the org chart
- Departed staff with live credentials is the most common finding there is.
- Demand evidence for compliance claims
- A certificate names a scope and a date; check both against the deal.
- Estimate the debt that will bill after closing
- What must be spent, on what, and how soon: remediation belongs in the price.
From findings to the deal.
- Rank findings by consequence and likelihood
- A long unranked list protects the reviewer, not the buyer.
- Price remediation into the transaction
- Findings that do not move price, terms, or plan were not worth finding.
- State what integration will demand
- Connecting or absorbing the target is a project; scope it before signing.
- Record the rejected alternative
- Write down what walking away would have cost; the record protects the decision either way.
Want this run against a real target?
Say what the deal assumes about the technology. The review tests exactly that, and the report follows this structure.