The contractor who left three years ago still owns part of your product
Here is a scene that plays out in data rooms more often than founders want to believe. A buyer's lawyer asks for signed IP assignments covering every person who touched the codebase. The founder pulls up the cap table, the employee agreements, the contractor invoices — and there's a gap. A guy named Dave built the original payments module in 2022. Dave was a contractor. Dave was paid promptly and parted on good terms. Dave never signed a Proprietary Information and Inventions Assignment Agreement.
Legally, Dave still owns that module. You paid for the work, but in most jurisdictions paying for code does not automatically transfer authorship of it — that requires a written assignment at the time of creation. Until Dave signs a confirmatory assignment, the company you are selling does not have clean title to a piece of its own product. And the buyer just found the most powerful renegotiation lever in the deal.
This is the single most common failure in technology due diligence, and it is entirely self-inflicted. A study of tech M&A deals found a surprising lack of dedicated IP due diligence on the buy side historically (Pinsent Masons) — but that era is over. Today's PE acquirers run chain-of-title verification as a standard gate, and an unbroken paper trail is the price of admission, not a nice-to-have.
Why the gap is worth more to the buyer than to you
Once an assignment hole surfaces, the buyer's options are all in their favor. They can demand a holdback against the risk, carve the affected IP out of the deal, or simply price the uncertainty into a lower number. Meanwhile, the leverage shifts to whoever can sign the missing document — which is often a former employee or contractor with no remaining stake in your outcome and every reason to negotiate hard. A $500 oversight in 2022 becomes a five- or six-figure ransom in diligence.
The fix has nothing to do with lawyers being clever and everything to do with timing. Run a comprehensive employee agreement audit roughly a year before you intend to go to market. Every employee, every contractor, every intern, every co-founder who ever left — each needs a signed PIIAA on file. Where there are historical gaps, secure confirmatory assignments while you still have leverage and goodwill, long before an LOI is anywhere near the table. Chasing signatures after a buyer has flagged the problem is the most expensive possible time to do it.
A scanner will read your entire codebase in 48 hours — and it doesn't care about your roadmap
The second document failure is one founders can no longer hide from, because the buyer no longer needs your cooperation to find it. Automated composition-analysis tools can ingest your full codebase and produce a complete map of every third-party dependency and its license terms in roughly two days. The "don't ask, don't tell" approach to open source died the moment that became routine.
The numbers are not comforting. Across audited codebases, essentially 100% contain open source components, and the audit data shows the overwhelming majority carry some form of license conflict (Black Duck Audit Services, 2025 Open Source Security and Risk Analysis Report). Most of those conflicts are cleanup, not catastrophe. But one category is a genuine valuation killer: the copyleft, or "viral," license — GPL v2 and v3 being the headline examples.
Why one library can put your whole product at risk
The mechanism is brutal in its simplicity. If your proprietary software statically links to a GPL-licensed library, the GPL's terms can reach into your code and require that the linked work be made available under the same open-source terms. To a buyer planning to run your product as a closed, commercial asset, that turns "proprietary IP" into "code anyone can demand to see." The remediation is not a memo — it is engineering: you rip out the offending library, find or build a clean-room replacement, or buy a commercial license, and then you re-test everything that depended on it. That work takes weeks to months, and if it surfaces during diligence, the cost comes straight out of your purchase price as "technical debt" the buyer now has to fund.
The one artifact that flips the script: a self-generated SBOM
The defense is to do the buyer's audit before the buyer does. Generate a Software Bill of Materials proactively — a line-item inventory of every third-party component, its exact version, and its specific license. The SBOM does two things at once. It lets you find and remediate copyleft exposure on your own timeline, when you still control the narrative. And it signals to the acquirer that engineering discipline runs deep here — that you knew what was in your product before they asked. The deals that go sideways are the ones where the buyer's scan finds something the seller didn't know existed. Don't be the seller who learns about a GPL dependency from the other side's lawyer.
If your "secret sauce" lives in your CTO's head, you're selling a hostage situation
The first two failures are about proving you own what you built. The third is about proving anyone other than you can run it. Patents protect the what; trade secrets protect the how. But a trade secret only counts as an asset a buyer will pay full price for if it has been written down. If the architecture, the data flows, and the genuinely clever parts of your system exist only in the founder's or the lead engineer's memory, you have not built IP — you have built key-person risk, and buyers price that risk into earnouts and retention packages instead of cash at close.
The tell shows up in real time during diligence. A buyer asks how your data ingestion pipeline actually works. If the answer is the CTO standing up and drawing it on a whiteboard because no current document describes it, every experienced acquirer in the room hears the same thing: this system is one resignation away from being unmaintainable. M&A integration already fails at high rates — much of it driven by the acquirer's inability to absorb and operate what they bought (McKinsey & Company). Undocumented technology is one of the most reliable ways to land on the failing side of that statistic, and buyers know it. That is exactly why they pay a premium for transferability.
The Technical IP folder you build before you go to market
Turning tribal knowledge into a priced asset is concrete work, not a philosophy. Before you open the data room, assemble a "Technical IP" folder that contains:
- Current system architecture diagrams — the C4 model is the cleanest way to show the same system at four useful levels of zoom.
- API documentation in a machine-readable spec (OpenAPI / Swagger), not a stale wiki page.
- A trade-secret register: the actual algorithms, customer and pricing logic, and data models you treat as confidential — plus a record of the access controls and security measures that prove you've protected them as secrets.
- The third-party dependency map — the SBOM from the previous section — so the codebase story is complete in one place.
Each of those documents moves a specific conversation. Architecture diagrams answer "can my team run this without the founder." The OpenAPI spec answers "can we integrate this fast." The trade-secret register answers "is the secret sauce legally protectable and ours." Together they shift the negotiation away from "earnout contingent on the founder staying two years" and toward "cash at close." Start the folder now, well ahead of any process. Documentation written under deal pressure looks exactly like what it is, and buyers read the difference.
