In 2019, a technical review of a nine-figure acquisition target at First American Financial — the world’s largest title insurer, managing 770 applications, 900 engineers, and a 4TB SQL Server database containing 100 million US property records — revealed that the technical reality of the target did not match the deal thesis. The company walked away from the acquisition. That single technology review prevented what would have been a $120M mistake.
Most buyers miss what that review found — not because the information was hidden, but because the standard diligence process is not built to surface it. Financial statements, legal review, and customer interviews do not tell you whether the codebase you are acquiring can support the growth plan your model assumes.
flowchart TD
TH[Deal thesis] --> G{Does technical<br/>reality match?}
R1[Code review] --> G
R2[Architecture docs] --> G
R3[Security posture] --> G
R4[Team capability] --> G
R5[Data infrastructure] --> G
R6[Integration map] --> G
G -->|Match| M[Price with confidence]
G -->|Gap found| W[Price adjustment, escrow,<br/>or walk away — the 120M call]
class M good
class W warn
classDef good fill:#163a26,stroke:#44cc77,color:#d7ffe6;
classDef bad fill:#3a1620,stroke:#ff5555,color:#ffd9d9;
classDef warn fill:#3a2e16,stroke:#ffaa33,color:#ffe9c7;
classDef accent fill:#15233b,stroke:#4488ff,color:#dce9ff;
What Most Buyers Get Wrong
The conventional M&A process treats technical due diligence as a checkbox. Buyers hire a generalist firm that produces a risk summary document, an engineering team conducts a walkthrough, and someone reviews the top-level architecture diagram. The result is a review that validates the surface presentation rather than stress-testing the underlying reality.
The gap between documentation and production reality is where most buyers lose money. What a target’s CTO presents in a data room walkthrough reflects how the system was designed and how it is supposed to work. What the codebase actually contains reflects the decisions made at 11:00 PM under a launch deadline, the third-party integrations that were never properly documented, the database schema that was modified 40 times and never reconciled with the original design, and the deployment scripts that only two engineers understand well enough to run without causing an outage.
Documentation-level diligence misses all of that. Code-level review surfaces it.
The Five Things Buyers Most Commonly Overlook
1. Key-Person Dependency
Every engineering organization has someone whose departure would cause serious operational disruption. In well-run organizations, that risk is managed through documentation, knowledge transfer protocols, and team cross-training. In most acquisition targets, that risk is concentrated in one or two people who hold critical institutional knowledge in their heads.
This matters in M&A because those individuals frequently do not stay post-close. The acquisition changes their equity position, their reporting structure, and their sense of ownership. If the systems they built and maintained cannot be operated or extended by the remaining team without them, the buyer has acquired a platform with a hidden dependency that the purchase price did not account for.
A proper technical diligence process includes a team capability assessment — an evaluation of whether the engineering team, minus the individuals most likely to leave, can sustain and develop the platform. This is one of the most important questions in the review and one of the least frequently asked.
2. Legacy Integration Depth
A modern front-end is not a modern platform. In industries with decades of operational history — insurance, financial services, healthcare, logistics — it is common for a contemporary web application to sit on top of batch processing infrastructure that has not changed since the mid-1990s. The target looks current in a demo because the interface is current. The underlying data processing logic is running in a system that was built before the first iPhone.
I encountered exactly this pattern during enterprise work with Geologistics, a $1.5B global freight forwarder operating across 140+ countries. The integration landscape included AS/400 systems, mainframe processing, EDI protocols, and BizTalk orchestration — infrastructure that predated most of the engineers touching it. None of that was visible at the surface level. All of it was critical to operations.
Buyers who do not conduct integration mapping as part of diligence discover this post-close, at which point the modernization cost is a surprise rather than a negotiated term.
3. Technical Debt as a Post-Acquisition Cost
The standard approach to technical debt in M&A is to note it as a risk and apply a general discount. The problem with that approach is that “general discount” is a guess. Technical debt has a specific remediation cost, a specific velocity impact, and a specific risk profile — all of which can be estimated with reasonable accuracy by someone who has read the code.
The correct frame for technical debt in an acquisition context is not “how messy is this” — it is “what will it cost to operate this platform under our growth plan.” A company planning to 3x the user base on an acquired platform needs to know whether that platform’s architecture can support that scale without a rewrite, and if a rewrite is required, what it will cost and how long it will take.
The LERETA modernization — a four-year, $20M investment in rebuilding two flagship products — began with an architecture assessment that quantified the existing technical debt and established a realistic picture of what the legacy platforms could and could not support. That assessment shaped the investment thesis. Buyers need the same clarity before close, not after.
4. AI Capability Claims That Do Not Hold Up
In the current environment, nearly every technology company includes AI capability in its positioning. A meaningful portion of those claims do not survive architecture review.
There is a material difference between a thin wrapper over a general-purpose language model API and a purpose-built AI capability with proprietary training data, documented fine-tuning methodology, and measurable performance benchmarks. Both can be described as “AI-powered” in a marketing deck. One is a defensible technical asset; the other is a feature available to any developer with an API key.
Technical diligence should evaluate AI claims specifically: what is the actual architecture, what data is the model operating on, how is performance measured, and what is the replication risk if a competitor simply calls the same API. Buyers paying an AI premium should be certain the premium reflects an actual technical advantage rather than a positioning decision.
5. Security Posture as Liability Exposure
Security vulnerabilities discovered after close become the buyer’s liability. A vulnerability that existed in the target’s codebase becomes a breach risk in the combined entity — with the buyer’s customer base, the buyer’s data assets, and the buyer’s regulatory obligations now in scope.
Material security issues — unpatched dependencies, weak authentication implementations, inadequate data encryption, undisclosed past incidents — are discoverable in diligence if the review is structured to find them. Most diligence processes allocate insufficient time and technical depth to security review. The cost of that gap is realized post-close.
What Good Technical Due Diligence Actually Covers
A properly structured technical diligence engagement addresses six areas:
Code review: direct examination of the production codebase, not documentation about it. What does the code actually contain? What is the quality level? What patterns were used? What technical debt is embedded in the implementation?
Architecture documentation: does the documented architecture match the production reality? Are there undocumented dependencies, shadow systems, or components that exist in production but do not appear in the architecture diagrams?
Security posture: authentication and authorization patterns, dependency vulnerability scanning, data handling and encryption review, and any disclosed or discoverable past incidents.
Team capability assessment: an evaluation of the engineering team independent of key individuals. Can the team sustain the platform? What would change if the top two engineers departed in the first 90 days post-close?
Data infrastructure: data model quality, data lineage documentation, and whether the data assets support any AI, analytics, or data-driven value claims in the deal thesis.
Integration map: a complete picture of every external integration — APIs, third-party systems, data feeds, and operational dependencies — including which ones are documented and which ones are discovered only by reading the code.
How the First American Review Actually Unfolded
The headline number is easy to remember. The work behind it was less tidy.
Context matters here. First American had acquired more than 80 companies in the prior decade and was carrying roughly 700 software applications across 15+ subsidiaries — overlapping CRMs, redundant policy-management systems, half-integrated data pipelines that had been promised post-close and never finished. The enterprise architecture team I was part of spent months auditing that estate and trying to consolidate it. That context shaped the diligence approach: I had already seen, at scale, what acquired technology actually looks like once the deal closes and the consolidation work begins. The cost is rarely on the financial model.
The target in question presented well. The data room had the documents you would expect — architecture diagrams, integration inventories, a clean security questionnaire, capability claims aligned to the deal thesis. The standard process would have moved to confirmation. I asked for code access and database access instead, and spent time directly inside the systems rather than inside the documentation about them.
What surfaced was a familiar pattern dressed up in current packaging. The architecture diagrams described a service-oriented platform; the production reality was a small number of monolithic applications with service-shaped wrappers on top, sitting on a database whose schema had drifted significantly from what was documented. Data quality at the row level did not match what was claimed at the aggregate level — the same record was represented in multiple incompatible ways across systems that were supposed to be the single source of truth. Operational knowledge of how the most important batch jobs actually ran was concentrated in two engineers, neither of whom was structurally locked in to stay through the integration period. The capability claims that justified a meaningful piece of the valuation depended on data assets that, on inspection, were not the assets described.
None of that was hidden in a deceptive sense. It was hidden in the sense that documentation-level review does not surface it and a checklist diligence process is not built to ask the questions that would. The recommendation to walk away from the roughly $100M deal was straightforward once the picture was clear — a $120M correction relative to the value the platform would have actually delivered post-close, before counting the consolidation cost First American was already absorbing on its existing portfolio.
The general lesson from the First American years, repeated across dozens of integration reviews: M&A in technology-heavy industries is riddled with overlapping systems and undisclosed technical debt that compound for years post-close. Private equity firms in particular live with the consequences of acquisitions where the technical reality was not stress-tested before the wire transfer. A diligence process structured to do that stress-testing is the single highest-leverage step in the transaction.
The Standard That Prevents $120M Mistakes
The First American Financial review worked because it was structured to find the gap between the deal thesis and the technical reality. The question going in was not “is there any risk?” — there is always risk. The question was “does this platform do what we are paying for it to do, and can it support what we intend to do with it after close?” When the answer to that question is no, the most valuable output of a diligence process is a clear recommendation to walk away before the check clears.
Most technical diligence processes are not built to reach that conclusion because they are not structured to ask that question with sufficient rigor. The result is that buyers close on assets they have not genuinely evaluated, and the discovery happens post-close at full acquisition cost.
The technical assessment and M&A advisory services on this site are structured around the kind of code-level, architecture-level, and team-level review that actually surfaces these issues before they become post-close surprises. If you are in or approaching a process and want to understand what a rigorous technical review looks like, reach out directly.
