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?"
Independent technical assessment for investors, acquirers, and founders — a report you can put in front of a board.
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:
If the target is already under LOI and the clock is running, the fastest way to turn this checklist into a number you can negotiate with is to have an independent team run it —
book a call and we'll scope the audit to your deal →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.
For acquisition-type-specific guidance, see: technical due diligence for private equity, for B2B SaaS acquisitions, for investors, for e-commerce businesses, for AI/ML products, and for HR and payroll software. If you're a seller preparing for diligence, see our seller's guide.
If you're a founder preparing your own technical foundation for a raise — rather than an investor evaluating a target — see what investors look for in your technical team and the engineering checklist before Series A.
Reading the checklist is useful. Having someone run it is better. Hunchbite conducts technical due diligence for acquisitions and investments — codebase, architecture, security, and a written report with risk levels and deal structure recommendations. We've assessed software across industries and deal sizes.
→ Technical Due Diligence Service
Call +91 90358 61690 · Book a free call · Contact form
We conduct technical due diligence for acquisitions and investments — codebase, architecture, security, scalability, and team risk — and deliver a written report with risk levels, remediation costs, and deal-structure recommendations. You walk into the negotiation knowing exactly what you're buying.
Trusted by VMAC Industries, TKD Logistics, Astitva Jewellery & more. See our recent work →
Fixed-price, no hourly billing · No obligation · We tell you upfront if we're not a fit
A practical guide for business owners whose developer has gone silent, quit, or become unresponsive — how to secure your code, assess the damage, and get your project back on track.
8 min readRescuing SoftwareYour 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 read