Imagine you’ve just wired eight figures into escrow for a profitable B2B SaaS company. The financials looked clean. The product had paying customers, a reasonable churn rate, a tidy codebase reviewed by your technical team. You did everything right. Six months later, the product is barely functional and three of your top five customers have quietly started evaluating competitors.
This isn’t hypothetical. It’s the pattern behind a significant portion of software acquisitions that go sideways, and the reasons are almost never the ones acquirers thought to look for.
The Setup: A Textbook-Looking Deal
In 2017, a private equity firm acquired a mid-market legal document automation platform that had been quietly profitable for a decade. The due diligence process ticked every standard box. Revenue was recurring and growing. Gross margins were strong. The seller’s representations looked solid. The two engineers who had built most of the system were offered retention packages and stayed through the transition.
What the acquirers had missed was harder to see in a spreadsheet. Those two engineers were not just employees. They were the documentation, the architecture, the tribal knowledge about why certain bizarre decisions existed in the codebase, and most importantly, they were the reason enterprise customers renewed. Clients called them by name. Contracts were implicitly trust relationships with specific people.
Both engineers left within fourteen months of acquisition. Neither was treated badly. The culture just changed, the priorities shifted, and the work became less interesting. They moved on. The acquirers had purchased the legal right to the software. They had not purchased the software.
What You Actually Own
When you acquire a software company, you typically receive: the IP assignment, the codebase in its current state, the customer contracts, the brand, and whatever cash and receivables are in the deal. This is what shows up in the purchase agreement.
What actually generates the value of a software business rarely appears in any legal document. Consider the categories:
Institutional knowledge. A ten-year-old SaaS product carries a decade of decisions, workarounds, and context that only exist in the heads of the people who built it. Code comments tell you what something does. They almost never tell you why it does it that way, or what happened the last time someone tried to change it. This knowledge doesn’t transfer with the acquisition. It transfers with the people, imperfectly, over time, if you’re lucky.
Customer relationships. Enterprise B2B software is sold by people and renewed by relationships. The champion inside your biggest customer account often has a loyalty to a specific account manager or founder, not to the product. When that person leaves, the relationship is suddenly up for re-evaluation. One enterprise customer is a trap, not a business, and a single key-person dependency in the go-to-market is nearly the same problem.
Operational muscle memory. The founder who ran a lean team of six people probably has strong opinions about hiring, support triage, and incident response that she has never written down because she never had to. Her team absorbed those standards through proximity. Post-acquisition, that team is now reporting to someone new with different instincts. The little things start slipping.
Culture as product quality control. This sounds soft. It isn’t. In small software teams, culture determines what gets merged and what gets sent back for rework, how seriously on-call rotations are taken, whether technical debt is tracked or ignored. You can inherit a high-quality codebase and watch it decay in eighteen months if the people who cared about quality are gone.
Why the Legal Fiction Persists
Acquisition due diligence evolved primarily in an era of physical assets. You can look at machinery. You can inspect inventory. You can title real estate. The frameworks for auditing knowledge-intensive businesses are still catching up.
Most technical due diligence processes are built to surface risk rather than map value. Can we run the code? Are there security vulnerabilities? Is there licensing exposure? These are reasonable questions. But they’re asking whether you can keep the lights on, not whether you can make the business grow. The softer questions, who actually knows how this works, which customers would leave if the lead salesperson left, what has this team never had to write down because everyone just knew it, get much less rigorous treatment.
Private equity in particular has a structural problem here. The deal team that did the acquisition is often not the operating team that inherits the business. Knowledge gaps compound at the handoff.
What Smart Acquirers Do Differently
They treat talent retention not as an HR task but as an asset protection task. The retention package for your two most senior engineers should be sized like the insurance policy it is, because that’s what it is. Losing them is not an employee relations problem; it’s a product integrity problem.
They spend time before close understanding who actually owns each major customer relationship, not on paper, but in practice. Which sales rep does the CFO at your biggest customer actually call? That person’s continued employment has a dollar value and should be treated accordingly.
They do knowledge transfer as a formal deliverable. A structured process where key employees document critical institutional knowledge, edge cases they’ve handled, architectural decisions and the reasoning behind them, and vendor or partner relationships they manage personally. This isn’t perfect but it’s far better than nothing, and it creates accountability for both sides.
They stay humble about the product roadmap for the first six months. One of the reliable ways acquirers destroy value is by immediately pivoting strategy, replatforming features, or consolidating the acquired product into their existing infrastructure before they understand what they have. The software nobody bought turned out to be worth more is a familiar phenomenon, and it usually reflects how non-obvious the value in software products can be to outside observers.
The Uncomfortable Conclusion
The legal definition of what you own when you buy a software company is well-established. The practical definition is hazier and more honest: you own the assets that couldn’t leave even if they wanted to. The code, the domain, the contracts, the brand. Everything else is a bet on continuity.
The best software acquisitions are structured with that bet front of mind. The worst ones treat the human and cultural dimensions as secondary to the financial and legal ones, then wonder why the product started deteriorating right after close.
Software isn’t a machine that keeps running after you buy it. It’s closer to a garden. You bought the land. The people who knew what was planted and why are now your biggest retention risk.
