Who Owns Your Code? IP Ownership Is the Clause Most Founders Skip
You paid for the software — but do you actually own it? Source code, repositories, infrastructure and design assets are often quietly retained by the agency. Here's what real IP ownership means, the warning signs in a contract, and why it decides whether your product is an asset or a hostage.
May 16, 2026
3 min"We Paid For It, So It's Ours" — Usually Wrong
Most founders assume that paying an invoice transfers ownership of the software. Legally, it often does not. In many jurisdictions the author of the code holds the copyright by default — not the client who commissioned it — unless the contract explicitly transfers it. A paid invoice buys you a license to use the result, which is a very different thing from owning it.
The gap rarely surfaces during a happy project. It surfaces when you want to change agencies, raise funding, get acquired, or simply move your repository — and discover the leverage was never yours.
What "Ownership" Actually Has To Cover
Real ownership is not one line that says "all IP belongs to the Client." It is a checklist of concrete assets that must be named and handed over:
- Source code & full Git history — not a zip of the final build, the actual repository with commits.
- Design files — Figma/source assets, not just exported PNGs.
- Infrastructure & accounts — domain, DNS, hosting, database, CI/CD pipelines, environment variables, third‑party API keys, registered in your organization.
- Third‑party licenses — fonts, stock media, paid libraries: which are yours, which are the agency's demo placeholders you must replace.
- No residual rights — the agency keeps no exclusive right to maintain, host, or block you from hiring someone else.
If any of these is missing, you do not fully own the product. You own a dependency on the people who built it.
Red Flags To Catch Before You Sign
Read the contract for these specifically:
- IP "transfers upon final payment" — fair, but make sure final is clearly defined and not open‑ended.
- "The Agency grants the Client a license" — a license is not ownership. You want assignment/transfer language.
- "Proprietary framework" or "internal boilerplate" the agency reuses — clarify whether your build depends on code you are not allowed to take with you.
- Source code delivered "on request" or "at project end" — it should live in your organization's repository from day one.
- No mention of infrastructure handover — the most common way clients stay locked in even with code "ownership."
Why This Is a Business Decision, Not a Legal Footnote
IP ownership directly changes the value of what you are building:
- Fundraising & due diligence: investors check who owns the codebase. Ambiguous IP is a deal‑slower or a valuation cut.
- Vendor independence: clean ownership means you can change partners without a rebuild — your negotiating power, not theirs.
- Continuity: if the agency disappears, your product keeps running because you hold the keys.
Off‑the‑shelf SaaS gives you speed but never ownership. Custom software is only a strategic asset if the ownership is real. Otherwise you have paid custom prices for a black box you can't open.
How We Handle It at OKSoftware
We treat ownership as a default, not an upsell. The repository sits in your organization from the first commit. Infrastructure and accounts are provisioned under your name. On delivery you get full source, history, and documentation — and there is no proprietary lock‑in that prevents you from continuing without us. You hire engineering capacity; you keep the asset.
If you are commissioning software right now, do one thing before signing: ask the vendor, in writing, to list every asset that becomes yours and exactly when. A partner who builds clean, transferable systems will answer in a paragraph. Hesitation is the answer.
Planning a custom build or auditing an existing one? Talk to a Lead Engineer — no salespeople, straight answers about architecture and ownership.