A few months ago, a business owner called me in a bit of a panic. She wasn't happy with her current developer and wanted to switch to someone new. Simple enough, right? Then she asked her developer to hand over the source code for her website so a new team could take it from there.
The answer she got back was not what she expected: "I can give you access to the live site, but the code itself isn't something I can just hand over."
She had paid for that website. She assumed that meant she owned it. It turns out, that is not always how it works.
This mix-up is more common than you'd think, and it rarely comes from bad intentions on either side. It usually comes from a contract that never spelled out who owns what. So let's walk through what "owning" your software actually means, why it's not automatic, and the one question that can save you a lot of stress down the road.
Why Paying For Software Doesn't Automatically Mean You Own It
Here's a rule that surprises a lot of people: in general, under U.S. copyright law, the person who writes the code owns it, even if someone else paid for it. Paying the invoice does not, by itself, transfer ownership.
There's an idea called "work for hire" that some business owners assume covers this. It doesn't always. That rule was built mainly for employees, not outside developers or agencies. When you hire an independent contractor or a development firm, custom software usually falls outside the narrow list of situations where "work for hire" applies automatically.
So what actually decides who owns the code? The contract. If the agreement your business signed does not clearly say the code belongs to you, there's a real chance the developer still owns it, even years later, even after the project is finished and paid for in full.
I want to be clear about something: this is general, plain-English information, not legal advice. Copyright rules can vary depending on where your business is located and the specific wording of your contract. If you want a definite answer for your situation, it's worth having a lawyer look at the actual agreement.
Ownership vs. A License to Use: What's the Real Difference
Think of it like this. Owning a house means you can renovate it, rent it out, sell it, or knock it down. Renting a house means you can live in it comfortably, but you need the landlord's permission for almost everything else.
Owning your software's source code works the same way. If you own it, you can modify it, move it to a new hosting provider, hand it to a different developer, or rebuild parts of it, all without asking anyone's permission.
If you only have a license to use it, you're renting. You can use the software the way it was built to be used. But changing it, moving it, or letting a new team dig into the code often requires permission from whoever actually owns it, and that permission is not guaranteed.
Neither option is automatically the wrong choice for every business. Licensing can be a normal, reasonable arrangement, especially for off-the-shelf products built for many customers. The problem shows up when a business believes it owns fully custom software it paid to have built, and later discovers it only has a license.
A Simple Example
Picture a local restaurant that pays a developer ten thousand dollars to build a custom online ordering system, built just for that one restaurant. Three years later, the restaurant has grown and wants a bigger company to add delivery tracking and loyalty rewards.
If the restaurant owns the code, the new company can simply pick up where the old one left off. If the restaurant only holds a license, the new company may need to start over from scratch, because the party that owns the code isn't required to hand it over, and may not even want to.
That difference can mean redoing months of work and spending money twice for the same features.
Why This Matters Most When You Want to Switch Providers
Most business owners never think about code ownership on day one. Why would they? Everything is working fine, and the relationship with the developer feels good.
The moment it matters is when that relationship changes. Maybe your developer raises their rates. Maybe they get busy with other clients and stop responding quickly. Maybe you simply outgrow them and need a bigger team. This is closely related to what I've written about choosing a software development partner in the first place, because the exit terms deserve just as much attention as the hiring terms.
If you don't own your code at that point, switching gets harder and more expensive. You may be starting over rather than continuing forward. That's also why relying on one person for your entire system carries risk beyond just ownership, something I cover in the hidden cost of depending on one key person.
The Question to Ask Before You Sign Anything
Before you sign a contract for custom software, ask this one question directly: "Will I own the finished code outright, or am I only licensed to use it?"
A good developer or agency should be able to answer that clearly, without dancing around it. If the contract only mentions a license, that's not automatically a red flag. Just make sure it's a decision you made on purpose, not something you find out about later.
It's also worth asking whether ownership transfers immediately, or only after final payment. Many contracts tie the transfer of rights to full payment being received, which is fair, but you want to know that up front rather than assume it.
Because this touches on legal rights and contract language, it's genuinely worth having a lawyer review the specific agreement before you sign. A short conversation with a lawyer now is a lot cheaper than discovering the answer the hard way, years into running your business on software you thought was yours.
You don't need to become a legal expert to protect yourself here. You just need to ask the right question at the right time, and know enough to recognize the answer when you hear it.
If you're not sure where your current software stands, or you're about to start a new project and want to make sure the ownership terms are clear from day one, let's talk through your situation.