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.
Due diligence by deal type
The core checks below apply to every deal. What you weight most depends on what you're buying. Start here if you already know the deal type:
- Need the short version? The technical due diligence checklist is a one-page list you can hand to your team.
- Buying a small SaaS business: technical due diligence for micro SaaS acquisitions.
- Buying a larger SaaS company: technical due diligence for a SaaS acquisition.
- Buying a mobile app: technical due diligence for mobile apps.
- Buying a marketplace: technical due diligence for marketplaces.
- Buying enterprise software: technical due diligence for enterprise software.
- Acquiring a company's internal tools: technical due diligence for internal tools.
- Acquiring a team, not a product: technical due diligence for an acquihire.
If you'd rather have someone run the checks for you, our technical due diligence service delivers a written report with risk levels and remediation costs.
Why technical due diligence matters
The cost of getting it wrong
- Rebuilding a codebase post-acquisition typically costs 50–100% of the original development investment
- Security vulnerabilities can result in data breaches, regulatory fines, and destroyed customer trust
- Scalability limitations can cap growth regardless of market demand
- Technical debt can consume 40–60% of engineering capacity, turning a productive team into a maintenance crew
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.
The due diligence checklist
Category 1: Architecture
| 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?"
Category 2: Code quality
| 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?"
Category 3: Security
| 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?"
Category 4: Infrastructure and operations
| 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?"
Category 5: Test coverage
| 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?"
Category 6: Team and knowledge
| 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?"
Category 7: Licensing and compliance
| 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?"
Technical Due Diligence
Independent technical assessment for investors, acquirers, and founders — a report you can put in front of a board.
Scoring the results
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:
- 28–35: Technology is a strong asset. Proceed with confidence.
- 21–27: Technology is functional but needs investment. Factor improvement costs into the deal.
- 14–20: Significant technical risk. Either negotiate a substantial discount or plan for a partial rebuild.
- 7–13: Technology is a liability. Strongly consider whether the acquisition makes sense at the proposed price.
How findings affect the deal
Negotiation leverage
Every issue identified is a dollar amount that can be deducted from the asking price:
- Critical security vulnerability requiring immediate fix: ₹3L–₹10L
- No automated tests (will need to build): ₹5L–₹15L
- Architecture doesn't scale (will need partial rewrite): ₹10L–₹30L
- No CI/CD (will need to build): ₹2L–₹5L
- Key-person dependency (risk mitigation): ₹5L–₹20L
How much each finding can take off the asking price
Typical deduction per finding, on one scale. The security figure is per critical vulnerability.
- No CI/CD (will need to build)₹2L – ₹5L
- Critical security vulnerability requiring immediate fix₹3L – ₹10L
- No automated tests (will need to build)₹5L – ₹15L
- Key-person dependency (risk mitigation)₹5L – ₹20L
- Architecture doesn't scale (will need partial rewrite)₹10L – ₹30L
Present findings with remediation cost estimates. This isn't about being adversarial — it's about accurate valuation.
Deal structure options
Based on findings, you might propose:
- Price reduction proportional to remediation costs
- Escrow holdback released after issues are resolved
- Retention bonuses for key technical team members
- Warranty period where the seller fixes discovered issues
- Walk away if the technical risk exceeds the business opportunity
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 →The bottom line
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.
Need a technical due diligence audit?
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
Ask an AI assistant about this guide: ChatGPT · Claude · Perplexity