A technical due diligence checklist, with what “red” looks like
This technical due diligence checklist is the one I work from when reviewing a software company before an investment or acquisition. It’s grouped by area – architecture, code and delivery, infrastructure, security, data, team, IP and licensing, and costs – and each item says what to check and what a red answer looks like.
Use it to scope a review, to prepare as a seller, or to pressure-test a report someone else wrote. It isn’t a form to tick. The value is in following up on the answers that sound rehearsed.
What is technical due diligence?
Technical due diligence is an independent assessment of a company’s technology, done for a buyer or investor before a deal closes. It checks whether the software can support the business plan, what it will cost to fix what’s broken, and whether anything should change the price, the terms or the decision.
It’s different from a code audit, which an owner commissions to understand their own system, and from a penetration test, which probes the running system for exploitable vulnerabilities. Good due diligence leans on evidence – repository history, deploy logs, cloud bills, incident records – rather than management’s description.
Before you start: request list
Send this before the first session. How quickly and completely it comes back is itself a signal.
- Read-only access to source repositories, including history.
- Read-only access to the cloud console and billing for the last 12 months.
- Architecture diagram, however rough, and a list of third-party services the product depends on.
- Incident log or postmortems for the last 12 to 24 months.
- Org chart for engineering, with tenure, and a list of contractors and agencies.
- Any previous security assessments, pentest reports or compliance certifications.
- Open source license scan, if one exists.
- Current roadmap and the engineering headcount plan that supports it.
1. Architecture and scalability
- Can the system handle the plan? Ask for current peak load and the growth the deal model assumes. Red: no one knows current peak load, or the plan needs 10x and nothing has been tested beyond 2x.
- Single points of failure. One database server, one region, one queue worker, one person. Red: a critical component with no failover and no documented recovery procedure.
- Data model fit. Does the schema match how the business works today? Red: core concepts bolted on through JSON blobs or “misc” columns, or tenant separation enforced only in application code with no tests.
- Coupling. How hard is it to change one part without breaking another? Red: a “microservices” system where every deploy has to be coordinated across services.
- Pending rewrites. Is there a rewrite in progress or planned? Red: a half-finished rewrite running alongside the old system with no end date. This is one of the most expensive situations to inherit.
2. Code quality and delivery
- Deploy frequency and lead time. How often does code reach production, and how long from merge to live? DORA metrics are a useful frame. Red: monthly or manual deploys done by one person.
- Tests. Are the money paths, permissions and core workflows covered? Red: coverage concentrated in trivial code, or a test suite that’s been disabled in CI.
- Change failure rate. How often do deploys cause incidents or rollbacks? Red: nobody tracks it, and engineers describe deploy days as stressful.
- Dependency health. Language runtime and framework versions, and whether they’re in security support. Red: a framework several major versions behind with no upgrade path planned.
- Areas nobody touches. Ask engineers which parts of the code they avoid. Red: the avoided area is billing, auth or the data pipeline.
- Code review. Are changes reviewed before merge? Red: direct pushes to main as normal practice.
Some mess is normal. Inconsistent style, thin docs and a few large classes are the cost of having shipped. My guide to technical debt explains how to tell harmless debt from the kind that compounds.
3. Infrastructure and operations
- Infrastructure as code. Can the environment be recreated from a repository? Red: production configured by hand in a console, with nobody sure what’s running.
- Backups and restores. When was a restore last tested, and how long did it take? Red: backups exist but have never been restored.
- Monitoring and alerting. Would the team know about an outage before customers? Red: customers are the alerting system.
- Incident history. Frequency, duration and whether postmortems led to changes. Red: repeated incidents with the same root cause.
- On-call. Who gets paged and how often? Red: one person always on call, or no on-call at all for a product with SLAs.
- Vendor lock-in. Which managed services would be painful to leave? Red: deep dependence on a niche vendor with no exit plan and a contract renewal due soon.
4. Security and data protection
- Secrets. Where do credentials live? Red: secrets committed to the repository, or shared admin accounts.
- Access control. Who has production access, and is it reviewed? Red: former employees or contractors who still have access.
- Authentication and authorization. Is authorization checked server-side on every request? Red: permissions enforced only in the front end.
- Personal data inventory. Can the team list where customer personal data is stored, including logs, analytics and backups? Red: they can’t.
- Past incidents and breaches. What happened, who was told, what changed? Red: an incident that wasn’t disclosed to customers when it should have been.
- Payment data. Does card data ever touch the company’s servers? Red: raw card numbers in the database or logs. Most companies should be using a processor’s hosted fields or checkout so this can’t happen.
5. Team and key-person risk
- Bus factor. For each critical system, how many people could fix it at 2am? Red: one, and they’re a contractor or a founder planning to leave after the deal.
- Tenure and attrition. Who joined and left in the last two years, and why? Red: senior engineers leaving in a cluster.
- Retention after close. Which people are essential, and are they incentivized to stay? Red: key engineers with fully vested equity and no retention plan.
- Outsourcing. How much work is done by agencies? Red: the agency holds the knowledge and the relationship ends at close.
- Roadmap realism. Does the roadmap fit the team you’re getting? Red: the business plan assumes a delivery pace the team has never achieved.
6. IP and licensing
- IP assignment. Has every employee and contractor who wrote code signed an assignment? Red: early code written by founders or freelancers before the company existed, with no assignment.
- Open source licenses. Run a license scan. Red: GPL or AGPL code inside a product that’s distributed or, for AGPL, offered as a network service, without a plan for compliance.
- Third-party code and data. Are any SDKs, datasets or models used outside their license terms? Red: scraped training data or a commercial library used beyond its seat count.
- Domain names, repositories and accounts. Are they owned by the company? Red: the main repository or cloud account sits under a founder’s personal account.
- Escrow obligations. Are there customer contracts with source code escrow clauses? Red: obligations promised to customers that nobody has been fulfilling.
7. Costs and unit economics
- Cloud spend vs revenue. Monthly infrastructure cost and its trend. Red: costs growing faster than revenue with no explanation.
- Per-customer cost. Do a few large customers drive most of the infrastructure cost? Red: a contract priced below what it costs to serve.
- Third-party SaaS and API costs, including AI model usage. Red: usage-priced dependencies with no budget controls.
- Cost to remediate. Sum the effort estimates for the red items. This is the number that should feed into price, holdbacks or the 100-day plan.
Turning the checklist into a decision
A useful report doesn’t list every finding at equal weight. Sort them into three buckets: issues that change the deal (price, warranties, retention, escrow), issues for the first 100 days, and normal mess you accept. Attach a rough effort estimate to each of the first two.
If you want someone to run this for you, I do technical due diligence for acquirers and investors, and pre-sale reviews for founders who want to find problems first. Funds can find more on independence and timing on the page for investors and acquirers.
Questions
What should a technical due diligence checklist include?
At minimum: architecture and scalability, code quality and delivery practices, infrastructure and operations, security and data protection, team and key-person risk, IP and open source licensing, and infrastructure costs. Each item should state what evidence to look at and what a red answer looks like.
Who performs technical due diligence?
Usually an independent technical advisor, a specialist firm, or an experienced CTO engaged by the buyer or investor. Internal teams sometimes do it for acquisitions, but an outside reviewer is more likely to ask uncomfortable questions and less likely to be anchored by the deal.
What are the biggest red flags in technical due diligence?
Key-person dependence on someone leaving after the deal, missing IP assignment, copyleft code in a distributed product, untested backups, customer data nobody can locate, and a half-finished rewrite. Each can change the price or structure of a deal.
How should a seller prepare for technical due diligence?
Run the checklist on yourself first. Fix the cheap items – IP assignments, a license scan, a tested restore, a current architecture diagram – and write honest explanations for the rest. Buyers forgive known problems far more readily than surprises.
Want this run for a specific deal?
Tell me the timeline and the thesis. I’ll tell you what I can cover in the time available and what a report from me would look like.
GMT+2 · Full EU overlap · US East mornings