When a company acquires a software business, the due diligence process typically covers financials, legal, and market position in exhaustive detail. The technology – the thing the company actually sells – often receives a cursory review at best. Someone senior spends a day or two looking at the repository, writes a paragraph saying the code is “reasonable for a company of this stage,” and the deal proceeds.
This is a mistake. Technical debt, security vulnerabilities, architectural limitations, and team dependencies can cost millions in post-acquisition remediation. A structured technical due diligence process identifies these risks before the deal closes, not after.
Here is a checklist, organised into five categories.
1. Architecture
Architecture reveals the fundamental constraints and capabilities of the system. It is the hardest thing to change after acquisition, so it deserves the closest scrutiny.
Dependency inventory. What external services, libraries, and frameworks does the system depend on? Are any of them deprecated, unmaintained, or approaching end-of-life? A system built on an abandoned framework is a system that will require significant investment just to keep running. Check the age and maintenance status of every major dependency.
Coupling assessment. How tightly coupled are the system's components? Can modules be modified independently, or does every change ripple across the codebase? High coupling makes every future change expensive and risky. Look for signs: shared global state, circular dependencies between modules, business logic scattered across layers.
Scalability characteristics. What are the system's scaling limits? Has it been tested under load? Are there bottlenecks in the data layer, the API layer, or the infrastructure? If your acquisition thesis depends on growing the user base, you need to understand whether the architecture can support that growth or whether it will require rearchitecting first.
Data architecture. How is data stored, accessed, and migrated? Are there multiple databases with inconsistent schemas? Is there a clear data model, or has the schema evolved organically without a coherent plan? Data architecture problems are among the most expensive to fix post-acquisition.
2. Security
Security issues discovered after acquisition become the acquirer's liability. Understanding the security posture before closing is essential.
Vulnerability scan. Run automated vulnerability scanning against the codebase and its dependencies. Look for known CVEs in third-party libraries, SQL injection vectors, cross-site scripting opportunities, and insecure authentication patterns. This is a baseline, not a full assessment, but it surfaces the obvious risks quickly.
Compliance status. Does the system handle data subject to regulatory requirements – GDPR, PCI-DSS, HIPAA, SOC 2? If so, what is the current compliance posture? Are there documented policies and audit trails, or is compliance aspirational? The cost of achieving compliance post-acquisition can be substantial.
Access control. How are permissions managed? Is there a consistent authorisation model, or are access checks scattered throughout the code with inconsistent logic? Review how secrets are stored. Hardcoded credentials, API keys in configuration files, and tokens committed to version history are red flags that indicate systemic security hygiene issues.
Incident history. Request a log of past security incidents and how they were handled. The absence of any recorded incidents is not reassuring – it usually means incidents were not tracked rather than that they did not occur. A mature organisation has an incident log and post-mortems.
3. Code quality
Code quality determines the ongoing cost of maintaining and extending the system. Low-quality code is not just ugly – it is expensive.
Test coverage. What percentage of the codebase is covered by automated tests? More importantly, what kind of tests exist? A codebase with 80 percent coverage from unit tests but no integration or end-to-end tests has a different risk profile than one with 40 percent coverage that includes all three levels. Look at what the tests actually validate, not just the coverage number.
Dead code and unused dependencies. How much of the codebase is actively used? Dead code – modules, functions, and routes that are never called – is a maintenance burden and a confusion source for developers. Large quantities of dead code suggest that the team has been adding without removing, which indicates a lack of refactoring discipline.
Code duplication. How much logic is duplicated across the codebase? Duplication is a leading indicator of future bugs, because changes to duplicated logic must be applied in every location, and developers inevitably miss some. High duplication also suggests an absence of shared abstractions.
Consistency of patterns. Does the codebase follow consistent patterns for common operations – error handling, logging, data access, configuration, validation? Or are there three different approaches to the same problem in different parts of the system? Inconsistency increases cognitive load for developers and makes the system harder to reason about.
4. Operations
A codebase that cannot be reliably built, deployed, and monitored is a liability regardless of its code quality.
Deployment process. How is the software deployed? Is there a CI/CD pipeline with automated testing, or is deployment a manual process involving SSH and hope? What is the deployment frequency? How long does a deployment take? Can a deployment be rolled back, and how quickly?
Monitoring and observability. What monitoring exists? Are there alerts for error rates, latency, and resource utilisation? Can the team diagnose a production issue from logs and metrics, or does diagnosis require SSH access to production servers? The absence of monitoring infrastructure means the team is flying blind – issues are discovered by customers, not by systems.
Incident response. Is there a documented incident response process? Who gets alerted? What is the average time to detection and time to resolution? Does the team do post-mortems? An organisation without incident response processes is one where production issues are handled ad hoc, which means they take longer to resolve and are more likely to recur.
Infrastructure as code. Is the infrastructure defined in code (Terraform, CloudFormation, Pulumi) or configured manually? Manual infrastructure configuration is a single-point-of-failure risk – the configuration exists only in the minds of the people who set it up, and it cannot be reliably reproduced.
5. Team and knowledge
Technology does not exist independently of the people who build and maintain it. Understanding the team dimension is critical to assessing post-acquisition risk.
Bus factor. How many people understand each part of the system? If a single developer is the only person who understands the payment processing module or the data pipeline, that is a critical risk. The bus factor – the number of people who would need to be unavailable before a part of the system becomes unmaintainable – should be at least two for every critical component.
Documentation. Is there meaningful documentation? Not marketing documentation, but technical documentation: architecture diagrams, API specifications, runbooks for common operations, decision records for significant technical choices. Documentation quality correlates strongly with the team's ability to onboard new members and maintain the system as people leave.
Retention risk. What is the team's tenure? Are key engineers likely to stay post-acquisition? In many software acquisitions, the departing founders take critical knowledge with them. Understanding who knows what – and whether they are staying – is as important as understanding the code itself.
Development velocity. How quickly does the team ship? What is the average cycle time from ticket to production? Is velocity trending up, down, or flat? Declining velocity often indicates that technical debt is accumulating faster than it is being repaid, which is a leading indicator of future engineering challenges.
How AI code review accelerates the process
Traditional technical due diligence is expensive and slow. A thorough manual review of a large codebase takes a team of senior engineers weeks. In M&A contexts, time is often limited – the deal has a timeline, and the acquiring company cannot afford to spend months on technical assessment.
AI code review tools can dramatically accelerate the code quality, security, and architecture portions of the checklist. A full-codebase scan can identify dependency risks, vulnerability patterns, code duplication, dead code, and inconsistent patterns in hours rather than weeks. This does not replace human judgement – the operations and team categories require interviews and observation – but it provides a thorough baseline that human reviewers can build on.
The output of an AI code review is also more consistent and more thorough than a manual review. A human reviewer inevitably focuses on the parts of the codebase they examine and misses others. An AI scan reads every file. This is particularly valuable in due diligence, where the goal is to find the things the seller might not mention – the abandoned module with hardcoded credentials, the untested data migration script, the deprecated library that nobody has updated in three years.
For acquirers who run multiple due diligence processes per year, the efficiency gain is substantial. A tool that costs a one-time fee and scans an entire codebase in a few hours replaces what would otherwise be weeks of senior engineering time at consulting rates. The numbers make the decision straightforward.
Using the checklist
This checklist is not exhaustive – every acquisition has unique factors that require additional investigation. But it provides a structured starting point that ensures the critical categories are covered. The five categories – architecture, security, code quality, operations, and team – represent the dimensions that most often contain surprises after a deal closes.
The most expensive technical due diligence failure is not finding a problem and deciding to proceed anyway. It is not finding the problem at all. A structured checklist, combined with automated scanning, reduces the chance of that happening.