Template
Software due diligence checklist for startup codebases
Software diligence should answer whether the product can support the next business decision. The checklist has to connect repository evidence to deal, roadmap, security, and operating risk.
Section 1
Business question and scope
Start by naming the decision the diligence review is supposed to support. A seed investment, acquisition, vendor selection, rescue project, and CTO advisory review all need different emphasis.
- Decision being supported: invest, acquire, refactor, maintain, or rebuild
- Repository and systems included in scope
- Critical product flows that must be reviewed
- Known exclusions, unknowns, and required follow-up access
Section 2
Repository and delivery evidence
Validate whether the team can build, test, deploy, and explain the software without relying on undocumented knowledge.
- Languages, frameworks, lockfiles, and package managers
- CI status, release process, deployment targets, and rollback path
- Test coverage around auth, billing, data deletion, payments, and permissions
- Environment variable inventory and onboarding documentation
Section 3
Security and dependency review
Diligence does not need to prove a codebase is perfect. It does need to find the risks that can change the decision or the first 90 days of work.
- Committed secret signals and key rotation requirements
- Known vulnerable dependencies and upgrade blockers
- Authentication, authorization, tenant isolation, and audit logging gaps
- OpenSSF Scorecard or equivalent repository hygiene signals
Section 4
Architecture and maintainability
Map where change risk concentrates. The highest-value diligence finding is often a hidden coupling or operational bottleneck that changes the post-deal plan.
- Entry points, domain modules, database models, jobs, and external services
- High fan-in modules, dependency cycles, oversized files, and dead code
- Data migration, backup, observability, and incident-response assumptions
- AI-generated or rapidly generated code paths that need extra validation
Section 5
Risk memo and action plan
Close with a concise memo that separates existential risk from normal engineering debt. The output should help someone decide, not merely prove that a review occurred.
- Go, no-go, or conditional-go recommendation
- Top 10 risks with evidence and affected files
- 30/60/90-day repair plan with owners
- Issues or milestones for accepted remediation work
How to use this template
- Use this checklist when the codebase decision affects investment, acquisition, hiring, vendor selection, rescue scope, or a major roadmap promise.
- Keep ordinary startup mess separate from decision-changing risk. Missing docs may be normal; missing tenant isolation, billing tests, or a deployment path can change deal terms or the first 90 days.
- The final diligence artifact should be a conditional recommendation, not a general engineering review. State what is safe, what must be contained, and what information is still missing.
Sources and standards
Generate this from a real repository
CodeTruss fills the report with architecture evidence, health scores, findings, and a prioritized issue roadmap.
Start free