Technical Due Diligence Checklist (Print & Use)

How to use this checklist: Work through each category with the seller's codebase in front of you. Rate each item Pass / Fail / Partial. Count the fails — they become your negotiation points and remediation cost estimates. For a deeper explanation of why each item matters, see our full technical due diligence guide.

This is the checklist we run when clients ask us to evaluate software before an acquisition, investment, or major engagement. Print it, share it, or work through it live during access sessions with the target's engineering team. It's equally useful as a self-assessment — if you suspect something's wrong with a product you already own, the same items surface the early signs a software project is failing long before a deal is ever on the table.

---

Architecture

• Clear separation between frontend, backend, database, and any services
• API design is consistent — RESTful or GraphQL with versioning
• Data flow is traceable from user action to storage
• System can handle 10x current load without a full rewrite
• No critical business logic locked into a single third-party vendor
• Microservices (if used) have clear ownership boundaries — not a distributed monolith
• Architecture documentation exists and matches the actual system

Verdict: Pass / Partial / Fail    Notes: _______________

---

Code Quality

• Consistent naming conventions across the codebase
• No files named utils2.js, helpers_old, temp_fix, or similar
• No significant code duplication — DRY patterns in use
• Functions and files are reasonably sized (no 500-line functions)
• README with setup instructions that actually work
• Linting is configured and passes in CI
• Comments exist on complex or non-obvious logic
• New developer could be productive in < 2 weeks

Verdict: Pass / Partial / Fail    Notes: _______________

---

Security

• npm audit / equivalent: zero critical vulnerabilities
• Passwords hashed with bcrypt or equivalent — never plain text or MD5
• Authentication uses industry-standard library (OAuth, JWT with correct expiry)
• Authorization enforced at the API layer, not just the UI
• PII and sensitive data encrypted at rest
• All endpoints behind HTTPS
• No API keys or secrets hardcoded in source code or git history
• Server-side input validation on all user inputs
• SQL queries use parameterized statements — no string concatenation

Verdict: Pass / Partial / Fail    Notes: _______________

If you've reached the security section and realised you can't actually verify half of these items yourself — git history, encryption at rest, authorization at the API layer — that's exactly the work we do for a living, so

here's what our due diligence report covers →

---

Infrastructure & Operations

• Hosting is documented and accessible (no "only John knows the password")
• Automated CI/CD pipeline — no manual FTP or SSH deploys
• Separate dev, staging, and production environments
• Error tracking in place (Sentry or equivalent)
• Uptime monitoring with alerting
• Structured application logging with retention policy
• Automated database backups — verified with a test restore
• Infrastructure-as-code or documented runbooks for disaster recovery

Verdict: Pass / Partial / Fail    Notes: _______________

---

Test Coverage

• Unit tests exist for core business logic
• Integration or end-to-end tests cover critical user flows
• Test suite runs in CI on every push
• Tests pass consistently — no flaky tests disabled or skipped
• Coverage on critical paths is 40%+ (not a vanity metric)
• Team can explain what breaks if a given test fails

Verdict: Pass / Partial / Fail    Notes: _______________

---

Team & Knowledge Risk

• At least 2 developers understand each major component (bus factor > 1)
• New developer can set up and run the project locally in < 1 day
• Tech stack has a broad available talent pool
• Core team has been stable for 12+ months
• No critical deployment or access knowledge held by a single person
• Onboarding documentation exists and is current

Verdict: Pass / Partial / Fail    Notes: _______________

---

Licensing & Legal

• All open-source dependencies have permissive licenses (MIT, Apache, BSD)
• No GPL dependencies inside proprietary code
• GDPR / CCPA compliance in place: data deletion, privacy controls
• Industry-specific compliance met (PCI-DSS, HIPAA, SOC 2 if applicable)
• All code written under work-for-hire contracts — IP ownership is clear
• No code from previous employers or clients mixed in

Verdict: Pass / Partial / Fail    Notes: _______________

---

SaaS-Specific (skip if not applicable)

• Multi-tenant architecture with proper data isolation between customers
• Subscription billing infrastructure is owned and documented (not a black box)
• Usage/feature limits enforced at API level, not just UI
• Churn and MRR tracked with reliable attribution
• Customer-facing uptime SLAs are technically achievable by current infrastructure
• API rate limiting in place
• Webhook reliability — retry logic, failure logging

Verdict: Pass / Partial / Fail    Notes: _______________

---

Scoring

Count your fails and partials:

Result	Interpretation
0–4 fails	Technology is a strong asset. Proceed with confidence.
5–9 fails	Functional but needs investment. Factor remediation costs into the deal.
10–15 fails	Significant technical risk. Negotiate a substantial discount or plan a partial rebuild.
16+ fails	Technology is a liability. Reassess deal price and structure entirely.

Translating fails to INR (rough estimates)

Issue	Remediation Cost
No automated tests	₹5L–₹15L to build
Critical security vulnerabilities	₹3L–₹10L per issue
Architecture doesn't scale	₹10L–₹30L partial rewrite
No CI/CD pipeline	₹2L–₹5L to build
Key-person dependency	₹5L–₹20L risk mitigation
No monitoring or observability	₹2L–₹6L to instrument

Each fail is a line item in your negotiation.

---

What to do with your results

• Present findings with cost estimates — not as adversarial ammunition, but as accurate valuation inputs
• Propose deal structure adjustments — price reduction, escrow holdback, seller warranty period, or retention bonuses for key engineers
• Walk away if warranted — a technically insolvent product is not a bargain at any price

---

Not sure how to interpret what you found? Contact us — we run technical due diligence audits for acquisitions and investments. We'll review the codebase, rate every item on this checklist, and give you a written report with remediation cost estimates you can use at the negotiation table.