How to Run Technical Due Diligence Before Acquiring a Company

Most acquisition mistakes in technical companies aren't discovered during negotiations — they're discovered in the first 90 days after close, when integration begins and the real system becomes visible. A codebase held together by one engineer who's already planning to leave. Security vulnerabilities that create immediate customer notification obligations. IP ownership gaps in the core product that trace back to a contractor who never signed an assignment agreement. Infrastructure that runs on manual processes that no one documented and the outgoing team doesn't think of as unusual because they've always done it that way.

Technical due diligence done properly isn't a rubber stamp — it's a risk quantification exercise. The goal isn't to find reasons not to acquire; it's to understand what you're actually buying versus what you think you're buying, and to translate any gaps into either a price adjustment, a specific contractual protection, or a clear-eyed decision to proceed knowing the risk. Founders who skip technical diligence because they trust the founders they're acquiring from are confusing personal credibility with technical accuracy. Even honest founders don't know everything about their own codebases.

The asymmetry matters here. A thorough technical diligence process costs a few weeks of time and a modest advisory fee if you bring in external help. The cost of discovering a critical security vulnerability after close — one that requires immediate customer notification, regulator disclosure, and emergency remediation — can run into the millions and immediately impair the asset you just acquired. The math strongly favors spending on pre-close discovery.

Technical due diligence covers five distinct areas. Code quality and architecture evaluates whether the codebase is maintainable: is it well-structured, reasonably tested, and understandable to engineers who didn't write it? IP ownership evaluates whether the company actually owns what it's built: are contractor IP assignments in place, are there open-source licenses that create downstream obligations, and are there any third-party claims on core technology? Security posture evaluates the current attack surface: are there known vulnerabilities, how is access managed, and how would you find out if something went wrong?

Infrastructure and operational stability evaluates how the system runs day to day: is deployment automated or manual, what does the incident response process look like, and are there single points of failure in the infrastructure? Team and key person risk evaluates what happens when people leave: is knowledge distributed across the team or concentrated in one or two people, and what would it take to operate the system if those people weren't available? Each of these areas can produce findings that affect deal terms — which is why all five need to be covered, not just the ones that seem most obviously risky.

Phase one is a documentation review: architecture diagrams, tech stack documentation, third-party dependency lists, IP assignment agreements, any prior security assessments or penetration test results, and infrastructure diagrams. Ask for these before anything else. The completeness and quality of what you receive tells you something about the engineering culture before you've read a line of code. Teams that can't produce basic architecture documentation are telling you something about the operational risk you're inheriting.

Phase two is an engineering team interview, separate from the founder or business team interviews. Ask how technical decisions are made, what the team considers the biggest known problems in the codebase, and what they'd build differently if they were starting over. The answers to the last two questions are often more valuable than any code review, because the team knows where the problems live and usually hasn't been asked directly. Also ask: who on the team knows the most about how the system works overall, and what would it take to replace that person?

Phase three is a codebase review by an independent engineer or a specialized technical due diligence firm. This is non-optional. You're looking for code quality patterns, security issues, license compliance problems, test coverage, and the extent of technical debt. Phase four is an infrastructure audit: who has production access, what does the deployment process look like, what's the backup and recovery process, and what happens during an incident? The infrastructure audit can often be done in a structured half-day session with the right technical people from both sides.

Four categories of technical due diligence findings most commonly affect deal terms. Critical security vulnerabilities requiring immediate remediation are typically handled as a price holdback or an escrow — the acquirer holds a portion of the purchase price until the vulnerabilities are remediated to a defined standard. Missing IP assignments are handled by requiring retroactive assignment agreements from all former contractors and employees as a condition of close; if those people can't be found or won't sign, the IP risk gets repriced into the deal. Key person dependencies — where one engineer holds critical undocumented knowledge — are handled through retention agreements baked into the deal structure, often with vesting tied to knowledge transfer milestones.

Significant technical debt is the most nuanced finding because it's rarely binary. The question isn't whether there's technical debt — there always is — it's whether the debt is known and manageable, or unknown and structural. Known debt with a clear remediation roadmap is a cost you can underwrite. Unknown structural debt that makes the whole system harder to work with is a discount to the purchase price, because you're buying a slower engineering team until the debt is addressed. Quantifying this in engineering-hours-per-quarter and applying a cost multiplier gives you a defensible number to put on the table.