Buying a software company without a thorough technical assessment is like buying a building without an inspection. The financials might look clean, but underneath you could be inheriting years of shortcuts, unmaintained infrastructure, and code that nobody alive fully understands.
We have conducted technical due diligence for acquirers ranging from private equity firms to strategic buyers looking to absorb a competitor. The pattern is almost always the same: the seller presents strong revenue numbers, the buyer gets excited, and nobody looks hard enough at what is actually running in production until it is too late. By then you own the mess.
This guide covers what a real technical due diligence process looks like, what we evaluate, and the red flags that should make you renegotiate or walk away.
Why Technical Due Diligence Matters
Software companies are valued on their technology. That sounds obvious, but most acquisition processes spend 80% of the diligence period on financial and legal review and treat technical assessment as a checkbox. The problem is that technical debt is a financial liability that does not show up on the balance sheet.
We have seen acquisitions where the buyer discovered, post close, that the entire application needed to be rewritten within 18 months because the framework was end of life. That rewrite cost more than the acquisition price. A proper technology audit before closing would have surfaced this in a week.
The goal of technical diligence is not to find a perfect codebase. No codebase is perfect. The goal is to quantify the risk so you can price it into the deal or structure earnouts and escrows appropriately.
What We Evaluate
A comprehensive technical due diligence covers six areas. Skipping any one of them leaves blind spots.
Codebase quality and architecture. We review the source code for structure, readability, test coverage, and adherence to modern patterns. We look at how the application is organized: is it a monolith, microservices, or something in between? Does the system architecture make sense for what the product does? We check for hardcoded credentials, copy pasted logic, dead code, and the ratio of business logic to boilerplate. A well structured codebase signals a team that thinks about maintainability. A tangled one signals years of "just ship it" without refactoring.
Technical debt inventory. Every codebase has technical debt. The question is whether it is managed or out of control. We catalog outdated dependencies, deprecated APIs, missing tests, and known shortcuts. We estimate the cost and timeline to address critical items. Our technical debt guide covers how we think about categorizing and prioritizing debt, and the same framework applies during diligence.
Infrastructure and DevOps. Where does the application run? How is it deployed? Is there CI/CD, or does someone SSH into a server and copy files? We review cloud infrastructure, hosting costs, scaling characteristics, and disaster recovery. We check whether infrastructure is defined as code or manually configured. Manual infrastructure is a ticking time bomb because the person who set it up might not be part of the deal.
Security posture. We evaluate authentication and authorization, data encryption at rest and in transit, vulnerability management, and compliance status. If the product handles sensitive data, we check for SOC 2, HIPAA, or GDPR compliance as applicable. Our web app security checklist covers the baseline, but acquisition diligence goes deeper into penetration test history, incident response plans, and whether security has been a priority or an afterthought.
Data and integrations. We examine the database schema, data integrity, migration history, and backup procedures. We identify all third party integrations and evaluate vendor lock in risk. How dependent is the product on a single API provider? What happens if a key integration raises prices by 300% or shuts down?
Team and knowledge concentration. This is the one most buyers underestimate. We look at git history to understand who writes what code, how many contributors are active, and whether critical systems have single points of knowledge failure. If one engineer wrote 70% of the backend and they are not staying post acquisition, you have a serious risk.
Red Flags That Should Change the Deal
Some findings are normal and expected. Others should make you reconsider the terms.
No version control history. We have seen this. The code exists, but it was copied from a server with no git history. You have no way to understand how the system evolved or why decisions were made. This dramatically increases the cost of future changes.
Single tenant architecture for a multi tenant product. If the company sells SaaS but deploys a separate instance for every customer, your operational costs will scale linearly with revenue. Migrating to true multi tenancy is a major project that can take 6 to 12 months.
Key person dependency. If one developer holds all the context and they are leaving or not committed to a transition period, factor in the cost of a full knowledge transfer or even a partial rebuild. We have seen deals where this single risk added $500,000 or more in post acquisition costs.
No automated testing. A codebase with zero tests is a codebase where every change carries risk. You cannot safely add features, fix bugs, or refactor without the fear of breaking something. Budget for writing a test suite before making any major changes.
Expired or missing compliance certifications. If the product serves enterprise customers who require SOC 2 and the certification has lapsed, you are inheriting a compliance gap that takes 3 to 6 months and $50,000 to $150,000 to close.
How to Structure the Diligence Process
We typically run technical due diligence in two to three weeks, depending on the size and complexity of the target. The process follows this sequence.
Week one: We get access to source code repositories, infrastructure accounts, documentation, and architecture diagrams. We conduct automated scans and manual code review. We interview the CTO or lead engineer.
Week two: We dive deeper into the areas where week one surfaced concerns. We test deployment procedures, review incident history, and assess the data layer. We model the cost of addressing critical technical debt.
Week three (if needed): We produce a detailed report with findings categorized by severity, estimated remediation costs, and recommendations on deal structure adjustments.
The output is a document that the buyer can use to renegotiate price, structure holdbacks, or define post close technical milestones.
What Good Looks Like
Not every finding is negative. Here are signals that the technology is in solid shape: consistent commit history from multiple contributors, CI/CD pipelines that run on every merge, test coverage above 60%, infrastructure defined as code, documented runbooks for incident response, and dependencies that are within one major version of current.
These signals do not guarantee smooth sailing, but they indicate a team that cared about building something maintainable.
The Cost of Skipping Diligence
We have been brought in after acquisitions where the buyer skipped technical diligence. The stories are remarkably similar. Three to six months post close, the team discovers that a major component needs to be replaced. The original developers are gone. The documentation is nonexistent. What was supposed to be a growth acquisition turns into a stabilization project that consumes the entire engineering budget for a year.
Technical due diligence typically costs a fraction of the deal value. Skipping it is a gamble that rarely pays off. If you are considering an acquisition and need an independent technical assessment, you can compare our approach to hiring in house evaluators or learn more about how we work on consulting engagements.
If you are in the middle of a deal and need a technical assessment before close, reach out to our team. We will give you a clear picture of what you are buying.