A client of mine was three weeks from closing an acquisition. $4.2M deal, strategic fit was clear, the target's customer base was exactly what they needed. Their lawyer and accountant had reviewed the financials. Nobody had looked at the technology.
They called me at the end of week two. "Can you do a quick technical review? We just want to make sure there are no landmines."
There was one significant landmine. The target company's main application ran on a single server with no redundancy, no automated backups (the founder was doing manual backups to a local hard drive), and deployment was done by one engineer via direct SSH who was planning to leave the company after the acquisition closed.
This was not a deal-breaker - the technology could be fixed. But it was a negotiating point. The costs to stabilize the infrastructure before integrating it needed to be reflected in the price. We negotiated a $250K reduction in the acquisition price and a 90-day technical stabilization plan funded by the acquirer.
The technical due diligence paid for itself in the negotiation, plus avoided an outage in the first month of integration that would have been far more expensive.
What Technical Due Diligence Is Actually Trying to Find
Technical due diligence in an acquisition has three goals:
Find the liabilities. What are the technical problems that create cost, risk, or complexity that is not visible in the financial statements? Security vulnerabilities, fragile infrastructure, technical debt, compliance gaps, intellectual property issues, key-person dependencies.
Assess the integration complexity. How hard will it be to integrate this technology with the acquirer's existing systems? What are the dependencies, the data migration requirements, the API compatibility issues?
Validate the technical claims in the pitch. The target company has made claims about its technology - scalability, proprietary algorithms, unique technical capabilities. Are those claims accurate?
The output of technical due diligence is not a list of problems. It is a risk-adjusted view of the technology that informs the deal structure, the price, and the integration plan.
The Assessment Areas
A thorough technical due diligence covers five areas:
Codebase and architecture. I look at the repository structure, code quality, test coverage, and architectural choices. I am not doing a full code review - I am looking for patterns. Is the code maintainable? Is it documented? Does it have meaningful test coverage? Are there obvious security issues visible in the structure?
The specific red flags: a single file with 5,000+ lines of code (usually a God object that everything depends on), zero test coverage, no code review process visible in the commit history (everyone commits directly to main), or a monolithic structure that will make integration particularly difficult.
Infrastructure and operations. How is the system deployed? Where does it run? What happens when the primary database fails? Is there a monitoring system? Is there an on-call process? What does a deployment look like and who can do it?
The red flags: no automated deployments (everything is manual SSH), no backup system or unverified backups, no monitoring, production credentials known only to a single person.
Security posture. Are there obvious security vulnerabilities? Are credentials and secrets stored securely? Is there evidence of penetration testing or security audits? Are the dependencies up to date and free of known vulnerabilities?
The red flags: secrets committed to the codebase, outdated dependencies with known CVEs, no authentication on internal services, no evidence of security review.
Intellectual property. Who owns the code? Are there signed contracts with all contributors? Has open-source code been used in compliance with its licenses? Are there any GPL-licensed components in a proprietary product? Is there any litigation or dispute about IP?
The red flags: no contractor agreements, GPL code in a commercial product, no IP assignment clauses in employment agreements.
Team and knowledge concentration. Is the technical knowledge concentrated in one person? What happens if that person leaves? Is there documentation? Is there a process that would survive the departure of the key technical person?
This is often the most significant risk in small startup acquisitions. If the CTO or lead engineer built the entire system in their head and is leaving post-acquisition, the acquirer is buying a black box.
Red Flags That Change Deal Terms
Not every technical problem is a deal-breaker. Most technical problems are negotiating points - they translate into post-acquisition costs that should be reflected in the price.
Red flags that are typically negotiating points (cost items, not blockers):
- Technical debt requiring 3-6 months of remediation
- Infrastructure that needs to be rebuilt before it can scale
- Missing tests that create high-risk change management
- Manual deployment processes that need automation
Red flags that are more serious and may affect deal structure:
- Significant unresolved security vulnerabilities with exposed customer data risk
- Licensing violations that could result in IP litigation
- No IP assignment documentation for key contributors
- Infrastructure that has no redundancy and has a history of outages
Red flags that are deal-breakers or require significant legal protection:
- Evidence of existing data breaches that have not been disclosed
- Active litigation about IP ownership
- Compliance violations (HIPAA, PCI) that have not been remediated
- Key-person concentration where the departing founder is the only person who understands the system and refuses to provide adequate transition support
The pattern: technical problems are costs. Costs can be priced. Legal and compliance problems are liabilities that may not be priceable in advance.
The Process: What It Takes to Do It Right
A technical due diligence for an acquisition needs two to four weeks for a reasonably scoped target. Compressed timelines (less than a week) produce incomplete assessments that miss the things that are deliberately hidden or incidentally difficult to find.
The access you need:
- Repository access (read-only is fine)
- Access to infrastructure (cloud console access or a walkthrough with the lead engineer)
- Time with the technical team (one to two hours with the lead engineer, 30 minutes with each other engineer)
- Legal documents (contractor agreements, employment agreements, open-source license inventory if available)
- Incident history and post-mortems if they exist
The people the acquirer should not rely on for technical due diligence:
The target's own technical team. They have an incentive to present the technology positively. They will not lie to you - or at least, the honest ones will not - but they will explain away problems that an outside evaluator would flag. They also have blind spots about their own system.
A generalist auditor from the accounting or legal firm. Technical due diligence requires someone who has built and run software systems. Reading code and evaluating infrastructure requires domain knowledge that most non-technical auditors do not have.
What to Do With the Findings
The technical due diligence report should feed directly into the deal structure, not just the price.
The integration plan: what needs to be done in the first 90-180 days to stabilize the technology, and who is responsible? This should be part of the acquisition agreement, not an assumption.
The retention plan for technical knowledge: if the target company has a key technical person who is leaving post-acquisition, what transition period are they committed to? What documentation will be produced? This needs to be in the agreement.
The representation and warranty: what technical claims is the target company making, and what happens if they are materially false? Technical representations in acquisition agreements - about IP ownership, about absence of known security issues, about code licensing - need to be specific enough to be enforceable.
The price adjustment: quantify the cost of the remediations the due diligence identified and negotiate a corresponding adjustment, or a post-closing escrow that covers the cost of fixing what you found.
Technical due diligence is not a formality. It is the process that converts "I think this technology is solid" into "here is what the technology is worth, what it will cost to fix, and what we need the seller to warrant." That conversion is worth the investment.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr