Software Due Diligence Checklist: 47 Items for 2026

• Key Takeaway
• Who This Checklist Is For
• Domain 1: Pre-Engagement (5 items)
• Domain 2: Code Quality and Architecture (12 items)
• Domain 3: Intellectual Property and Licensing (8 items)
• Domain 4: Security and Compliance (6 items)
• Domain 5: Infrastructure and Operations (6 items)
• Domain 6: Engineering Team and Knowledge Risk (10 items)
• Domain 7: Post-LOI Synthesis
• How ContributorIQ Accelerates Items 38-46
• Frequently Asked Questions
  • What should a software due diligence checklist include?
  • How long does software due diligence take?
  • Who performs software due diligence?
• Conclusion

Key Takeaway#

A complete software due diligence checklist covers code, IP, security, infrastructure, and the engineering team behind the code. The most common reason post-deal value evaporates is not code quality. It is the silent departure of the one or two engineers who actually understood the system. This 47-item checklist treats engineering team risk as a first-class diligence workstream, not an HR footnote.

Who This Checklist Is For#

This checklist is built for:

• PE associates and partners evaluating a software target before a term sheet.
• VC partners performing technical diligence on a Series B or growth-stage investment.
• Corporate development teams at acquirers running technical diligence for a tuck-in or platform acquisition.
• Software founders and CTOs preparing for a transaction and wanting to know what buyers will ask.

Each domain below can be assigned to a different reviewer and run in parallel. The checklist is designed to be copied into a spreadsheet or Notion table and tracked through the deal.

Domain 1: Pre-Engagement (5 items)#

1. Confirm the data room scope. Code, infrastructure access, financials, customer lists, employee agreements, and engineering documentation should all be requested. Many sellers default to financials-only; push for the technical materials.
2. Sign a mutual NDA with explicit code review rights. Generic NDAs may not cover source code access. Ensure the buyer's reviewers (internal and external) are named.
3. Agree on a diligence timeline. Three to six weeks is normal for mid-market software. Confirm holiday windows that may push interviews out.
4. Identify the seller's key engineers in advance. Ask for a roster with title, tenure, and primary system responsibility. This list becomes the basis for interview scheduling and retention planning.
5. Lock the diligence team. Code reviewer, security reviewer, IP counsel, infrastructure reviewer, and engineering team analyst. Name them and confirm availability.

Domain 2: Code Quality and Architecture (12 items)#

6. Codebase inventory. Pull the full list of repositories, primary languages, lines of code, and last-modified dates. Watch for repositories that exist but have not been touched in 18+ months. Either dead code or hidden critical systems.
7. Architecture diagram. Request a current diagram. If none exists, that is itself a finding.
8. Build and test reliability. Can a fresh clone of each critical repository be built and tested in under an hour? Multi-day setup is a red flag.
9. Test coverage. Look for unit, integration, and end-to-end coverage percentages. Sub-30% coverage on revenue-critical paths is a concern.
10. Static analysis run. Run a linter and a SAST tool. Note the volume of critical findings.
11. Code review practices. What percentage of PRs are reviewed by someone other than the author? How many PRs land with one approval versus two?
12. Branching and release model. Trunk-based, GitFlow, or improvised. Improvised release processes scale poorly post-acquisition.
13. Technical debt inventory. Ask engineering leadership to list the top five debt items. Cross-reference with what the code actually shows.
14. Documentation coverage. README freshness, ADR (Architecture Decision Record) presence, internal wiki freshness. Stale documentation is the norm; ask how engineers actually learn the system instead.
15. Dead code and orphaned modules. What percentage of files have not been modified in 12+ months and have a sole historical author? These are knowledge-orphaned and high-risk to maintain.
16. Third-party dependencies. Volume, currency, and known vulnerabilities (run a dependency audit).
17. Code reuse and copy-paste density. High duplication is a maintenance multiplier and a signal of hurried scaling.

Domain 3: Intellectual Property and Licensing (8 items)#

18. Open source license inventory. Run a license scan. Catalog every dependency by license category. AGPL, GPL, and SSPL components in proprietary code paths are critical findings.
19. Contributor License Agreements. Have all contributors (employees and contractors) signed an IP assignment? Missing assignments from a former contractor can block a sale.
20. Patents. Inventory all patents, applications, and provisional filings. Confirm assignment chain to the corporate entity.
21. Trademarks. Confirm registration status and class coverage in major markets.
22. Trade secrets. What measures protect proprietary algorithms, models, or customer data? NDA coverage, access controls, exit interviews.
23. AI/ML training data provenance. If the product includes ML models, where did the training data come from? Has it been licensed for commercial use? Increasingly material in 2026.
24. Third-party content. Stock images, fonts, audio. Confirm commercial license coverage.
25. Customer-owned IP. Does any customer contract grant the customer ownership or perpetual rights to derived work? Common in early-stage consulting-to-product pivots.

Domain 4: Security and Compliance (6 items)#

26. Penetration test. Commission an external pentest. Catalog critical and high findings.
27. SOC 2 / ISO 27001 status. Active, in progress, or none. Lack of either is a finding for enterprise-focused targets.
28. GDPR, CCPA, HIPAA scope. Confirm what regimes apply and what controls are in place.
29. Secrets management. How are API keys, database credentials, and signing keys stored and rotated? Hardcoded secrets in git history are catastrophic and surprisingly common.
30. Incident history. Request 24 months of incident logs. Look for breaches, near-misses, and patterns.
31. Access control review. Who has production access? When was it last reviewed? How many former employees retain access?

Domain 5: Infrastructure and Operations (6 items)#

32. Cloud cost run rate. Monthly spend by provider. Trend over 12 months.
33. Reserved versus on-demand mix. Underutilized reservations or 100% on-demand both flag operational immaturity.
34. SLO/SLA performance. Last 12 months of uptime, error rate, and latency against stated SLAs.
35. Disaster recovery posture. RTO and RPO for critical systems. Last successful failover test.
36. Observability stack. Logs, metrics, traces. What does on-call actually use during an incident?
37. Infrastructure as Code coverage. What percentage of production infrastructure is in Terraform, Pulumi, or CloudFormation? Click-ops infrastructure is hard to migrate and hard to audit.

Domain 6: Engineering Team and Knowledge Risk (10 items)#

This is the domain most often shortchanged. It is also where post-deal value most often leaks.

38. Org chart with tenure. Every engineer, role, tenure, and reporting line. Flag anyone with tenure under six months on a critical system.
39. Bus factor analysis by repository. What is the minimum number of engineers whose loss would stall each critical system? See our bus factor guide for the calculation method. Any system at bus factor 1 is a material finding.
40. Key person dependency map. Which engineers are sole authors or sole reviewers for revenue-critical code paths? See our key person dependency guide.
41. Contributor lifecycle distribution. What percentage of the team is ramping up, at peak, plateauing, or winding down? Concentration of "winding down" engineers on critical systems is a leading indicator of post-deal departures.
42. Knowledge concentration metrics. Gini coefficient of commit distribution, percentage of single-author files, percentage of orphaned files (files whose only significant author has left). Tools like ContributorIQ compute these from git history in hours.
43. Hiring pipeline health. Open requisitions, average time to fill, accepted offer rate.
44. Voluntary attrition rate, 12 months. Calculate engineering-specific attrition. Industry baseline is 13-18%; sub-10% is excellent, over 25% is a critical finding.
45. Compensation benchmarking. Are key engineers paid at market? Below-market compensation on critical bus-factor-1 engineers is the single biggest post-deal departure risk.
46. Retention agreements. What stay bonuses or equity vesting acceleration is in place for key engineers, contingent on close?
47. Cultural fit interviews. For at least the top five engineers by criticality, the acquiring team should conduct structured 45-minute interviews focused on motivation, post-close interest, and concerns.

Domain 7: Post-LOI Synthesis#

After items 1-47 are complete, the diligence team should produce three artifacts:

1. Issue log, with severity rating (Critical / High / Medium / Low) and owner.
2. Engineering risk score, a composite of bus factor, attrition, single-author concentration, and key person dependency.
3. Integration plan, prioritizing the first 90 days of retention, knowledge transfer, and system handoff.

How ContributorIQ Accelerates Items 38-46#

ContributorIQ produces the engineering team risk subset of this checklist (items 38, 39, 40, 41, 42) automatically from git history, typically within hours of read-only repository access. PE diligence teams use it to replace four to six weeks of manual analysis with a quantitative baseline they can hand to operating partners. See our M&A use case for example outputs and methodology.

Frequently Asked Questions#

What should a software due diligence checklist include?#

A complete software due diligence checklist covers seven domains: pre-engagement preparation, code quality and architecture, intellectual property and licensing, security and compliance, infrastructure and operations, engineering team and knowledge risk, and post-LOI integration planning. The 47 items above are structured so a buyer can hand sections to their counsel, CTO, and security consultant in parallel.

How long does software due diligence take?#

For mid-market software acquisitions, technical due diligence typically takes three to six weeks from LOI to close. Code and infrastructure reviews run two to four weeks, team interviews one to two weeks, and synthesis another week. Quantitative engineering team analysis (bus factor, knowledge distribution, contributor lifecycle) can run in parallel and complete in days when using automated tools.

Who performs software due diligence?#

Buyers typically engage a mix of internal corporate development, external technical due diligence engineers, a code auditor, a security firm, and IP counsel. PE firms often retain specialist DD shops that bundle these competencies. Engineering team risk analysis is increasingly handled by automated platforms that quantify bus factor, key person dependencies, and contributor health from git history.

Conclusion#

The 47-item checklist above is the same structure used by experienced technical diligence teams. The mistake first-time acquirers make is treating engineering team risk as a soft, post-close concern. By the time that risk surfaces, the engineers who could have prevented it have already given notice. Treat items 38-47 with the same rigor as items 18-31 and you will close fewer bad deals.