A nine-figure deal collapsed because of what the diligence team found in a single repository. Not a breach. Not a lawsuit. Not a missing compliance certification. One codebase, three weeks of review, and a €120M acquisition price reduced to a walk-away by the acquirer's technology team.
I was brought in six weeks after the deal fell through, hired by the target company to do a post-mortem and help them get acquisition-ready for the next attempt. What I found was not a rogue engineering team or a negligent CTO. It was a company that had built genuinely impressive product capability on a foundation that no sophisticated buyer's technology team was going to accept.
This is what technical due diligence actually looks like from the other side of the table — and what it means for any company that will eventually be acquired, merged, or funded.
What Technical Due Diligence Actually Examines
Most founders believe technical due diligence is a code quality review. It is not. Code quality is one input among many — and not usually the most consequential one.
An experienced technology diligence team is building a model of three things: what it will cost to operate this technology going forward, what it will cost to integrate it, and what risks it conceals that don't appear on a balance sheet.
The review covers the architecture, the codebase, the infrastructure, the security posture, the engineering team structure, the deployment and incident history, the licensing and dependency graph, and the documentation. In a serious deal, the team will spend time with the engineers directly — not just the CTO — to pressure-test whether the presentation the leadership gave matches the technical reality on the ground.
The repo in question — the one that killed the deal — was the core platform. The product the acquirer was paying for.
What Was In the Repo
The company had been building for seven years. Seven years of product iteration, team changes, one serious pivot, and the accumulated decisions of at least four lead architects. The product worked. Customers loved it. Revenue was real and growing.
Here is what the diligence team found when they opened the repository.
No meaningful test coverage. The unit test suite existed — about 11% coverage, concentrated in the least business-critical parts of the codebase. The integration tests were skeletal. There were no end-to-end tests. There was no clear strategy for how changes were validated before they went to production other than manual QA on a shared staging environment.
Deployment was a manual tribal ritual. The deployment process was documented in a Confluence page that had not been updated in 18 months and referred to tools the team had since replaced. In practice, one engineer — who had been there since the beginning — ran deployments from his laptop using a sequence of commands he had memorised. He had taken one week of holiday in three years because he was afraid of what would happen if someone else tried to deploy.
A credentials and secrets problem. The diligence team ran a secrets scanning tool against the repository history. In the commit history — not in the current code, but in the history — they found database credentials, a private key for a third-party payment integration, and an API key for a cloud provider with production-environment permissions. The credentials had since been rotated. But the fact they had ever been committed indicated a culture and a process that a sophisticated acquirer's security team was not going to wave through.
No architecture decision records. Seven years of consequential architectural choices — framework selections, data model decisions, the migration away from the original infrastructure provider — with no written record of why any of it was done. The diligence team asked about three specific architectural choices that looked unusual. The answer to all three was "I'd have to ask [engineer who left two years ago]."
Dependency rot. The dependency graph contained 47 packages with known CVEs, 12 of which were rated high or critical. Several dependencies had not had a version update in over four years. Three core dependencies had been abandoned by their maintainers. None of this had been systematically tracked.
The history doesn't lie
A diligence team with access to your repository history can reconstruct the culture and practices of your engineering organisation going back years. Commit frequency, who commits, commit message quality, how quickly vulnerabilities are patched, whether secrets have ever been committed, the ratio of feature work to maintenance — all of it is in the history. Clean up the current state of the code if you want, but you cannot clean up the history.
Why the Deal Died, Specifically
The acquirer's technology team produced a 40-page diligence report. The conclusion was not that the product was bad. The conclusion was that the cost of remediating the technical risk before integration could proceed was €8–12M, with an 18-month timeline, and that the timeline carried high variance because the tribal knowledge concentrated in two individuals could not be reliably transferred on a schedule.
The acquirer modelled this against the acquisition price. The deal no longer made sense at the original number. They made a revised offer 30% below the original price, citing the diligence findings. The founders, who had been expecting to close at the original price and had mentally spent the money, rejected it. The deal died.
Six months later, the company was back in my office trying to understand how to get to a position where the next diligence team would produce a different report.
What "Acquisition-Ready" Actually Means
Acquisition-ready is not a state you achieve by hiring a consultant two weeks before a deal. It is a state you maintain — or it is not real.
| Dimension | Acquisition-Ready | The Deal That Died |
|---|---|---|
| Test coverage | 60–70%+ meaningful coverage, integration tests, CI gates | 11% coverage, no CI, manual QA |
| Deployment | Automated, repeatable, documented, runnable by any engineer | Manual, tribal, single point of failure |
| Secrets management | Vault or equivalent, no secrets in version control history | Credentials in commit history |
| Architecture documentation | ADRs for major decisions, current diagrams | Oral tradition, outdated Confluence |
| Dependency hygiene | Regular updates, zero critical CVEs, active maintainers | 47 CVEs, 3 abandoned dependencies |
| Bus factor | No single engineer is unacceptable to lose | Two people with irreplaceable tribal knowledge |
| Incident history | Written post-mortems, visible resolution patterns | Informal, undocumented |
| Licensing audit | Clean SPDX inventory, no GPL contamination in commercial code | Unknown — never reviewed |
The last row matters more than most founders realise. GPL or AGPL licensing in a commercial codebase — even via a transitive dependency — is a serious problem in an acquisition because it creates downstream licensing obligations the acquirer may not be willing to accept. A licensing audit takes a few days. Not knowing is not an option when a buyer's legal team starts asking questions.
The Timeline Problem
One of the most common things I hear from founders preparing for a transaction is "we'll sort out the technical debt before we go to market." The problem is that technical debt remediation cannot be scheduled like a sprint.
Rotating credentials and updating dependencies can be done in weeks. Building a meaningful test suite for a seven-year-old codebase without breaking production takes months, and requires engineers who understand the system deeply enough to write tests that actually reflect business intent. Creating architecture documentation when the people who made the decisions have left requires reconstruction and validation, not just writing. Reducing bus factor requires deliberate knowledge transfer, documentation, and time for the knowledge to actually move.
The realistic timeline for taking a company from the state I described to a state that would survive serious diligence is 12–18 months of consistent, prioritised effort. That is 12–18 months before you want to be in a process — not 12–18 months before you close.
The question to ask today
If a sophisticated buyer's technology team showed up tomorrow with full repository access and three weeks, what would they find? Not what you intend to fix, not what's on the roadmap — what would they find right now? If the answer makes you uncomfortable, that discomfort is worth acting on before it becomes someone else's leverage in a negotiation.
What I Helped Them Fix
Over the following 14 months, working with the company's CTO, we ran a structured remediation programme. The sequencing matters.
The sequencing of the remediation programme ran across three distinct phases:
The first 60 days were about the acute risks: secrets rotation and history sanitisation, critical CVE patching, and formalising the deployment process so that it was no longer dependent on one person's laptop. These were the things a diligence team would find within the first week and that would immediately raise flags.
The next six months focused on test coverage — not uniformly, but weighted toward the business-critical paths. Payment flows, user authentication, the core domain model. We used the risk register from the diligence report to prioritise. We brought test coverage in critical paths to above 70%. We built a CI pipeline that enforced it.
The final phase was documentation and knowledge distribution. We wrote architecture decision records for every significant architectural choice we could reconstruct. We ran structured knowledge-transfer sessions with the two engineers who held the tribal knowledge, recorded them, and turned them into operational runbooks. We ran a fire drill where neither of them was available and a team of three engineers successfully deployed and rolled back a release.
The company went back to market 14 months later. The diligence report from the next buyer's team was 12 pages. The deal closed.
The Lesson for Every Company That Will Eventually Be Acquired
Technical due diligence is not a hoop you jump through. It is an X-ray. Sophisticated buyers use it to understand what they are actually buying underneath the pitch deck. The gap between what the pitch says and what the repository shows is where value is transferred away from founders and toward acquirers — through price reductions, escrow arrangements, earn-out conditions, and walk-aways.
The companies that get the cleanest diligence reports and the fewest surprises in negotiation are not the ones who did a cleanup sprint before the process started. They are the ones who operated as if a diligence team might show up at any time, because they understood that acquirable companies are built, not prepared.
If you're building toward an exit, raising institutional capital, or want to understand honestly where your technology stands before someone else tells you — let's talk. A 30-minute discovery call is usually enough to know whether there's a problem worth solving now.