Most technical due diligence processes used in private equity and corporate M&A are inadequate. A generalist IT auditor circulates a 40-question survey to the target's CTO. The target responds "yes" to "do you use CI/CD?" and "yes" to "is your code in version control?" and the investment committee moves forward.
Six months post-close, the buyer discovers that the target's "auto-scaling microservices" all share a single synchronous database, that the founding engineer holds all institutional knowledge in their head and is about to resign, and that the platform cannot handle the 3x growth projected in the investment thesis.
Genuine technical diligence is not a checklist. It is a forensic investigation. Here is the actual diagnostic framework Anubis applies when auditing a software company before an acquisition.
1. Architecture: The Distributed Monolith Test
The first question is not "what does the architecture diagram say?" — it is "does the actual infrastructure match the diagram?" We inspect whether services genuinely operate independently or share critical synchronous data stores.
Red flags: All microservices connecting to a single unpartitioned PostgreSQL or MySQL instance. Cascading transactional queries that cross service boundaries. In-memory queues that lose state on restart.
The test: Under a 3x or 5x traffic load simulation, does each component scale independently, or does contention at the data layer cause cascading failure?
A microservices architecture diagram is a claim, not a fact. Verify whether services share a synchronous data store before trusting any scale projection.
2. Codebase Quality: What Automated Tools Miss
Automated static analysis catches syntax issues and obvious anti-patterns. It does not catch organizational brittleness. When we audit a codebase, we look for the code that nobody wants to touch — the files with no recent commits, the modules with no tests, the integrations with no documentation.
We also look for "hero code": core logic that lives exclusively in the head of one engineer and is not reproducible by the rest of the team. This is the single most underrated acquisition risk in software M&A.
Test coverage percentage is a vanity metric. Ask which parts of the system the team is afraid to deploy to production.
3. Infrastructure: The Disaster Recovery Reality Check
Most SaaS targets claim they have disaster recovery procedures. Very few have tested them. We require live documentation of the last RTO test — including actual recovery time, data loss, and manual steps required.
We also audit IAM policies for over-privileged roles, CI environment variables for hardcoded secrets, and cloud spend for orphaned resources. These findings frequently enable buyers to negotiate material price reductions or escrow holdbacks.
4. The Team: Bus Factor and Key Person Risk
The most dangerous technical risk in an acquisition is not code debt — it is personnel dependency. If one engineer resigns post-close and takes irreplaceable institutional knowledge with them, the acquisition economics collapse.
We map the deployment frequency and code authorship distribution across the team to identify single points of human failure. We also assess the engineering culture through private technical interviews, not HR-facing presentations.
The purpose of technical due diligence is not to find reasons to kill a deal. It is to ensure the investment thesis is based on technical reality, not marketing narrative. Every finding should be translated into a specific financial consequence: a remediation cost estimate, an escrow holdback recommendation, or a renegotiated purchase price.
Facing a technical acquisition decision? Anubis can independently assess the system, establish the technical facts, and give you a decision-ready recommendation.