A comprehensive checklist for evaluating software before an acquisition, investment, or major partnership — covering code quality, architecture, security, scalability, and hidden risks.
What is technical due diligence? Technical due diligence is an independent assessment of a software product's codebase, architecture, infrastructure, and team capabilities — typically conducted before an acquisition, investment, or major engagement. It reveals hidden risks: technical debt, security vulnerabilities, scalability limitations, and dependency on key personnel. The findings directly impact valuation, negotiation terms, and post-acquisition planning.
You're about to acquire a company, invest in a startup, or take over a software product. The financials check out. The market opportunity is real. The team seems strong.
But what about the software itself?
Technical due diligence answers a critical question: Is the technology an asset or a liability? A product with strong financials can hide a codebase that costs more to maintain than it generates. An impressive demo can mask fundamental architecture problems that prevent scaling.
This guide is the checklist we use when clients ask us to evaluate software before acquisition.
Technical issues discovered post-acquisition reduce your negotiating power to zero. Discovered during due diligence, they're leverage points for better terms or deal structure.
| Check | What to look for | Red flag |
|---|---|---|
| System design | Clear separation of frontend, backend, database, services | Monolithic spaghetti with no boundaries |
| API design | RESTful or GraphQL with consistent patterns, versioning | No API documentation, inconsistent endpoints |
| Data flow | Clear, traceable path from user action to data storage | Data flowing through 7 services for a simple operation |
| Scalability | Architecture can handle 10x current load with reasonable changes | Architecture requires complete redesign to scale |
| Third-party dependencies | Reasonable use of external services with fallback plans | Critical business logic dependent on a single vendor |
Key question: "Can this system handle 10x the current user base without a rewrite?"
| Check | What to look for | Red flag |
|---|---|---|
| Readability | Clear naming, consistent style, reasonable complexity | Cryptic variable names, 1000-line functions |
| Organization | Logical file structure, clear module boundaries | Files named utils2.js, helpers_old.js, temp_fix.js |
| Duplication | DRY code, shared utilities, reusable components | Copy-pasted blocks throughout the codebase |
| Documentation | README with setup instructions, architecture docs, inline comments on complex logic | Zero documentation, no README |
| Standards | Linting configured and passing, consistent formatting | No linter, mixed tabs and spaces, no code standards |
Key question: "Can a new senior developer be productive in this codebase within 2 weeks?"
| Check | What to look for | Red flag |
|---|---|---|
| Dependency vulnerabilities | npm audit / equivalent shows zero critical issues |
Critical CVEs in production dependencies |
| Authentication | Industry-standard auth (bcrypt, OAuth, JWT with proper handling) | Passwords in plain text, custom crypto, sessions that never expire |
| Authorization | Role-based access enforced at API level, not just UI | Hiding buttons in the UI but not checking permissions server-side |
| Data protection | Encryption at rest for sensitive data, HTTPS everywhere | PII stored in plain text, HTTP endpoints |
| Secrets management | Environment variables or secrets manager | API keys hardcoded in source code, committed to git |
| Input validation | Server-side validation on all user inputs | Client-side only validation, raw SQL with string concatenation |
Key question: "If this codebase were audited by a security firm tomorrow, would they find critical vulnerabilities?"
| Check | What to look for | Red flag |
|---|---|---|
| Hosting | Managed, documented, accessible | "Only John knows the server password" |
| CI/CD | Automated testing and deployment pipeline | Manual FTP deployments |
| Environments | Separate dev, staging, production | Production is the only environment |
| Monitoring | Error tracking, uptime monitoring, alerting | No monitoring, "we find out when users report" |
| Backups | Automated database backups, tested recovery | No backups, or backups that have never been tested |
| Logging | Structured logging with appropriate retention | console.log statements or no logging at all |
Key question: "If the production server crashes at 3 AM, how quickly can the system recover?"
| Check | What to look for | Red flag |
|---|---|---|
| Unit tests | Critical business logic has unit tests | Zero unit tests |
| Integration tests | Core user flows are tested end-to-end | No integration testing |
| Test reliability | Tests pass consistently, run in CI | Flaky tests, tests disabled, test suite broken |
| Coverage metric | 40%+ coverage on critical paths (not vanity metric) | 0% coverage or only trivial tests |
Key question: "How confident is the team that a code change won't break something unrelated?"
| Check | What to look for | Red flag |
|---|---|---|
| Bus factor | Multiple developers understand each major component | One person is the only one who can deploy or fix critical issues |
| Onboarding | New developer can set up and run the project in < 1 day | Setup takes a week and requires help from specific team members |
| Hiring | Technology stack has a large talent pool | Niche technology with few available developers |
| Turnover | Team has been stable for 12+ months | 3+ developers left in the past year |
Key question: "If the two most senior developers left tomorrow, how long before the team is productive again?"
| Check | What to look for | Red flag |
|---|---|---|
| Open-source licenses | All dependencies have compatible licenses (MIT, Apache, BSD) | GPL dependencies in proprietary code, or unlicensed code |
| Data compliance | GDPR, CCPA, or relevant regulations are addressed | No data deletion mechanism, no privacy controls |
| Industry compliance | Relevant standards met (PCI-DSS for payments, HIPAA for health) | Non-compliant handling of regulated data |
| IP ownership | All code written under work-for-hire with proper contracts | Ambiguous ownership, code from previous employers |
Key question: "Are there any legal or compliance risks that could result in forced changes or penalties?"
Rate each category on a 1–5 scale:
| Score | Meaning |
|---|---|
| 5 | Excellent — asset to the acquisition |
| 4 | Good — minor improvements needed |
| 3 | Acceptable — significant investment required |
| 2 | Poor — major overhaul needed, impacts valuation |
| 1 | Critical — could be a deal-breaker |
Total score interpretation:
Every issue identified is a dollar amount that can be deducted from the asking price:
Present findings with remediation cost estimates. This isn't about being adversarial — it's about accurate valuation.
Based on findings, you might propose:
Technical due diligence isn't optional for software acquisitions. The code is either an asset that generates value or a liability that consumes it. The difference between a ₹50L asset and a ₹50L liability can be invisible from the outside.
Invest 3–5 days in a proper audit. The cost is trivial compared to the cost of discovering problems after you've signed.
Need a technical due diligence audit? Request an assessment or book a call to discuss the scope. We've done technical DD for acquisitions and investments across industries — and we'll give you an honest picture of what you're buying.
If this guide resonated with your situation, let's talk. We offer a free 30-minute discovery call — no pitch, just honest advice on your specific project.
Your developer went silent. Your project is half-built. You don't know what state the code is in. This is the step-by-step guide to recovering your project and getting back on track.
10 min readRescuing SoftwareA practical decision framework for determining whether to repair your existing software or rebuild from scratch — with real cost comparisons, risk analysis, and honest guidance.
11 min read