Who Owns the Code? Protecting Your Business's Software & IP

Here's a question that catches a lot of business owners off guard: you paid someone to build your software — but do you actually own it? The uncomfortable answer is not automatically. Without the right terms in writing, the developer can legally keep the rights to the very thing you paid them to build. Getting this right is the difference between owning a genuine business asset and renting one you funded yourself.

Let's make sure you end up owning it.

"I paid for it" isn't the same as "I own it"

This surprises people, but in many places the default rule is that whoever writes the code owns the copyright — not whoever paid for it — unless a contract says otherwise. So paying the invoice doesn't transfer ownership on its own. You need an agreement that explicitly assigns the intellectual property to your business.

It's the same logic as commissioning a logo: pay a designer with no contract and you may have bought the right to use it, while they keep the rights. Software works the same way, and the stakes are higher.

What "owning" your software actually means

Real ownership is three things, and you want all three:

1. The source code. Not just a login to a running app — the actual code, handed over, so any developer can read, change, and host it.
2. The accounts and infrastructure. The hosting, the domain, the services it runs on — in your accounts, under your control.
3. The intellectual property, in writing. A legal assignment transferring the rights to your business.

With all three, you can host it anywhere, switch developers anytime, and treat the software as an asset on your books. Missing any one of them, and you're partly dependent on someone else.

The lock-in traps to watch for

Ownership problems usually show up as lock-in — ways you can't leave. The common ones:

• Proprietary platforms. A site or app built on a closed system you can't export — leave the provider and the software goes with them.
• "We host it for you" with no exit. Convenient until you want to move, and discover you can't get the code or the keys.
• Source code you never receive. You see the working product but never get the actual code, so you can't continue elsewhere.
• No IP assignment in the contract. Everything works fine — until a dispute, and you learn the rights were never yours.

Any of these turns software you paid to build into something you're effectively renting. (It's also a top reason projects can't be rescued when they stall — no code, no continuity.)

The terms to insist on (before work starts)

Get these into the agreement up front — they're far harder to add later:

• An IP assignment (or work-for-hire) clause transferring all rights to your business.
• A handover clause requiring delivery of the full source code and all accounts.
• No proprietary lock-in — confirmation you can host and continue the software independently.

A good partner says yes to all of this without hesitation — they expect it. Hesitation or vagueness on ownership is a red flag worth walking away over. (It's one of the key questions in how to choose a software development company.)

The bottom line

Paying for software doesn't automatically make it yours. Real ownership means the source code, the accounts, and a written IP assignment — all three. Watch for lock-in (proprietary platforms, no-exit hosting, code you never receive), and get the ownership terms in writing before work begins. Do that, and the software you paid for is a genuine asset you control — not a rental you funded.

Deciding who builds it in the first place? See agency vs freelancer vs in-house — and make ownership a non-negotiable whoever you pick.