The IP That Wasn't Owned

What happened

A promising software business was acquired for its product and its growing user base, and the whole of that value was the code. Diligence afterwards found the core software had been written years earlier by a freelance developer, paid by invoice, with no written assignment of the intellectual property. Under the applicable law that developer, not the company, owned it, so the seller had sold something he did not have. When the developer asserted his rights, the buyer discovered that years of daily use had never amounted to ownership.

The case, start to finish

Using something every day for years is not the same as owning it.

A company that was really a codebase

An anonymized composite, assembled from intellectual-property assignment and IP-diligence practice. This is general education rather than legal advice, and the rules involved vary by jurisdiction, which is itself part of the point. A promising software business is acquired: good product, growing users, real revenue. Almost the entire value of the deal is the code, because in a business like this there is very little else. No factory, no fleet, no inventory.

When a single intangible asset is effectively the whole company, ownership of that asset stops being a legal formality and becomes the deal.

The question that feels rude

Asking a seller to prove they own their own product is awkward in a way that asking for bank statements somehow is not. The product works. The team ships changes to it every week. The seller says, with no dishonesty at all, that of course the company owns its software. Everyone in the room has watched the thing run.

That is the trap, and it is worth naming precisely, because it is a reasoning error rather than a fraud. Possession, use and ownership are three separate conditions that usually coincide, and a buyer's intuition treats them as one thing. With physical property the intuition mostly holds. With intangible property the three come apart, and they come apart quietly, because nothing about daily use looks any different either way.

Where ownership actually lives

The core software had been built years earlier by a freelance developer, paid by invoice, with no written assignment of the intellectual property. Under the applicable law, that meant the developer rather than the company held the rights. The distinction that decided it is a general one worth carrying around: work created by employees typically belongs to the employer, while work created by contractors typically belongs to the contractor unless it has been assigned in writing.

The seller had not set out to sell something that was not theirs. They had simply never had a reason to check, because for years nobody had any incentive to raise the question. An acquisition supplies that incentive. In month four the original developer asserted their rights, against a buyer who had already paid. Dormant claims do not stay dormant once there is money on the other side of them.

Cheap to cure before, expensive to argue after

Found before closing, a missing assignment is an ordinary condition to satisfy. The seller wants the deal to complete, so either the assignment gets signed or the price moves to reflect the risk. Found after closing, the same gap is a negotiation the other side is well placed to win, and the seller's representations and warranties in the purchase agreement do not fix it. A warranty turns an ownership problem into a claim against a seller who has already been paid and whose exposure is usually capped. Meanwhile the developer goes on owning the code the business runs on.

For anyone running a small business built on something intangible, a brand, a design, a codebase, a course, the audit is far cheaper than the cure. It does not require a transaction to justify it. List what the business depends on, then ask for each item who made it and what they signed. Anything created by someone who was not an employee, without a written assignment, is worth resolving now, while the relationship is good and the answer is a favor rather than a claim. A qualified attorney is the right person to structure that, and the point of doing it early is that early is when it is still small.

Timeline

• Month 0 A promising software business is acquired, with a great product and growing users. The whole value is the code.
• Month 1 Diligence (too late) reveals the core software was built years earlier by a freelance developer, paid by invoice, with no written IP assignment agreement.
• Month 2 Under the applicable law, the developer, not the company, legally owns the code. The seller didn't actually own the core asset they sold.
• Month 4 The original developer asserts rights. The "asset" the buyer paid for wasn't the seller's to sell, because daily use was never ownership.

You're in the owner's chair

You’re buying a software company whose entire value is its code. Diligence should confirm who legally owns it, but the product works, the team uses it daily, and the seller says “of course we own it.” What do you do?

• Close — the company has used the code for years without a problem
• Rely on the seller’s IP warranty in the purchase agreement
• Trace the chain of title and cure the gaps before closing

Business model

An IP-driven software business where the intangible asset, the code, was effectively the entire company.

Revenue model

Real, growing software revenue, built on code the company used every day but did not legally own.

Cost structure

The catastrophic "cost" was buying a core asset with a broken chain of title, potentially not the seller's to transfer.

Strategic challenge

"The business uses it" was not "the business owns it." With intangibles, ownership is determined by who created the IP and what was signed, and a contractor paid by invoice with no assignment retained the rights, leaving the company (and the buyer) without clean, transferable title to its own core asset.

Key decision

The fateful omission was assuming ownership from daily use instead of tracing the chain of title, and not requiring the missing assignment be obtained and signed as a condition of closing.

What worked

Nothing in the process. The reusable lesson is that for IP-driven businesses, ownership is an on/off switch, so you verify the chain of title and fix gaps before closing (with a qualified IP attorney).

What failed

No IP diligence. The buyer paid for an intangible asset the company didn't legally own, on the assumption that building and using it meant owning it.

Risk factors

Unowned core IP (contractor/founder-created, no written assignment); assuming daily use means ownership; a broken chain of title; no assignment required before closing.

Lesson summary

With intellectual property, daily use isn't ownership; ownership lives in the signed agreements. Trace the chain of title for the core IP, verify protection and freedom to operate, and fix ownership gaps before closing (require the assignment be signed), with a qualified IP attorney. Confirm the asset is actually the business's to sell.

Key data

• The code (the whole value) Core asset
• None Written assignment
• The freelance developer Legal owner

Sources & basis

The business in this story is a stand-in, not a company you can look up. This case is an illustrative composite: the operator, the people and most of the dollar figures represent a pattern rather than reporting one firm's history. What the list below cites is the other half, the documented industry data and public reporting the composite was assembled from, including any real company whose published figures the case draws on by name. The mechanism and the arithmetic are real even where the business is not.

1. Intellectual-property due diligence and IP-assignment practice (jurisdiction-specific; general education, not legal advice)
2. Composite pattern: see the Intellectual Property Due Diligence and Legal Due Diligence lessons