Technical Due Diligence Checklist: What to Audit Before Acquiring a Software Company

A technical due diligence audit examines the codebase, architecture, infrastructure, team, and technical debt of a software company before acquisition. The goal is not to find every bug. It is to identify risks that affect valuation, integration timeline, or post-acquisition engineering cost. A $5M software acquisition with $2M in hidden technical debt is actually a $7M acquisition — and most buyers only discover the $2M after closing.

This checklist covers the seven audit areas that matter, in the order you should evaluate them. Each section includes what to look for, what the red flags are, and what questions to ask the target company's engineering team.

1. Code quality and architecture

What to audit:

• Language and framework versions — are they current, supported, or end-of-life?
• Codebase structure — is there a consistent architecture pattern (MVC, microservices, modular monolith), or has it grown organically without structure?
• Code review history — are pull requests reviewed before merging, or does the team push directly to main?
• Dependency audit — are third-party packages up to date? Any dependencies with known security vulnerabilities?
• Documentation — does meaningful technical documentation exist (architecture diagrams, API docs, deployment guides), or is the knowledge only in people's heads?

Red flags: Framework versions 3+ years behind current. No code review process. A single developer who is the only person who understands the codebase. More than 30% of dependencies have known vulnerabilities.

2. Test coverage and quality assurance

What to audit:

• Automated test coverage — what percentage of the codebase has unit tests? Integration tests? End-to-end tests?
• CI/CD pipeline — do tests run automatically on every commit? How often do builds break?
• Manual QA process — is there a QA team or process, or do developers test their own work?
• Bug backlog — how many known bugs exist? How old are the oldest ones? What is the severity distribution?

Red flags: Less than 20% test coverage on critical business logic. No CI/CD pipeline. A bug backlog with 100+ items, some older than 12 months. No automated tests at all is not uncommon in startups but represents $50,000–$150,000 in post-acquisition remediation cost.

3. Infrastructure and DevOps

What to audit:

• Hosting architecture — cloud (AWS, GCP, Azure), managed services, or bare metal? Is the infrastructure documented and reproducible (Infrastructure as Code)?
• Deployment process — how does code get from a developer's machine to production? Automated or manual? How long does a deployment take?
• Monitoring and alerting — is there application monitoring (error tracking, performance metrics)? Who gets paged when something breaks?
• Disaster recovery — are there automated backups? Has a restore ever been tested? What is the recovery time objective (RTO)?
• Monthly infrastructure cost — is it proportional to usage, or is there significant waste?

Red flags: Manual deployments (SSH into a server and pull code). No Infrastructure as Code. Backups that have never been tested. A single server with no redundancy. Monthly cloud costs that have grown 3x faster than revenue.

4. Security

What to audit:

• Authentication and authorisation — how are users authenticated? Is role-based access control implemented correctly?
• Data encryption — is data encrypted at rest and in transit? How are secrets (API keys, database credentials) managed?
• Previous security audits — has a third-party penetration test been done? When? What was found?
• Compliance requirements — does the product handle PII, PHI, or payment data? Is it compliant with GDPR, HIPAA, PCI-DSS as applicable?
• Incident history — has there been a data breach or security incident? How was it handled?

Red flags: Secrets stored in code repositories. No penetration testing ever performed. PII stored in plaintext. An unpatched security vulnerability in a customer-facing application. Any previous breach that was not disclosed to affected users.

5. Data architecture and integrity

What to audit:

• Database design — is the schema normalised appropriately? Are there obvious data integrity issues (orphaned records, duplicate data, missing constraints)?
• Data volume and growth — how much data exists? What is the growth rate? Are there performance issues at current scale?
• Data portability — can the data be exported? Is the company locked into a proprietary database or format?
• Migration history — are database migrations version-controlled and reversible?

Red flags: No foreign key constraints. JSON blobs used as the primary data store for relational data. Database queries that take 10+ seconds in production. No migration history — schema changes applied directly to the production database.

6. Team and knowledge concentration

What to audit:

• Team composition — how many engineers? What are their roles? How long has each person been with the company?
• Knowledge concentration — how many people can deploy to production? How many understand the full architecture? Is any critical system understood by only one person?
• Retention risk — do key engineers have retention agreements? Are there earnout structures tied to the acquisition?
• Contractor dependency — what percentage of the codebase was written by contractors who are no longer available?

Red flags: A single engineer who is the only person who can deploy, debug, or explain the core system ("bus factor = 1"). Key engineers with no retention agreement who plan to leave post-acquisition. More than 50% of the codebase written by people no longer with the company and no documentation of their work.

7. Technical debt and scalability

What to audit:

• Known technical debt — does the team have a documented list of shortcuts, workarounds, and deferred refactoring? What would it cost to address?
• Scalability ceiling — at what point does the current architecture stop working? Is it 2x current load? 10x? Has the system been load tested?
• Third-party dependencies — are there vendor lock-ins that would be expensive to exit? APIs that could be deprecated?
• Feature velocity — how long does it take to ship a new feature? Is velocity decreasing over time (a sign of compounding technical debt)?

Red flags: Feature velocity has decreased 50%+ over the past year. The architecture cannot handle 2x current load without a rewrite. Critical business logic in a third-party system with no migration path. The team says "we'd like to rewrite it" about more than one core system.

How long does a technical due diligence audit take?

A thorough technical due diligence audit takes 1–3 weeks depending on the size and complexity of the codebase. A small SaaS application (one repository, one database, 3–5 engineers) can be audited in 5–7 business days. A multi-service platform with several repositories, multiple databases, and a team of 15+ engineers takes 2–3 weeks.

The output is a structured report covering all seven areas above, with a risk rating (low, medium, high, critical) for each, a cost estimate for remediation of identified issues, and a recommendation on whether the technical state supports the proposed valuation.

Madgeek has conducted technical due diligence audits for software acquisitions across SaaS, eCommerce, and enterprise platforms. For more on our technical due diligence service, or to discuss an upcoming acquisition, get in touch.