Who Owns the Code When You Pay for Custom Software?

Most business owners assume that paying for software means owning it. You paid the invoice, so it’s yours — the same way it works with a delivery van or a new roof on the shop. It is a reasonable assumption, and under US copyright law it is wrong.

The default rule is that whoever writes the code owns it. Not whoever paid for it. That default only changes if a contract says so, in writing, in specific language. Plenty of small businesses discover this years later, at the worst possible moment: when they want to switch developers, sell the company, or simply move the application to a different host and find out they need permission from someone else to do it.

This is not a reason to be paranoid, and it is not a reason to hire a lawyer for every project. It is a reason to read one section of the contract carefully before you sign it. Here is what actually matters.

Why paying for it isn’t the same as owning it

Copyright attaches to code the moment it is written, and it belongs to the author. There is an exception called work-for-hire, which is where a lot of the confusion starts. Work-for-hire means the employer owns what the author produced — but it generally applies to actual employees working within the scope of their jobs. An outside development firm or a contractor is not your employee. The exception does not automatically cover them.

So when a development agreement is silent on ownership, the developer typically still holds the copyright. What you have is an implied license: permission to use the thing you paid for, on terms nobody ever wrote down. That is fine right up until you want to do something the developer would rather you didn’t — like hand the code to a competitor of theirs, or keep running it after you’ve stopped paying them a monthly fee.

The fix is not complicated. The contract needs to assign the copyright to you explicitly. A firm that intends to give you ownership will have no problem putting it in writing, because it costs them nothing to say plainly what they already meant.

Ownership, license, and source code access are three different things

These get used interchangeably in sales conversations, and they are not the same. Knowing the difference is most of the battle:

• Ownership — you hold the copyright. You can modify the software, hire anyone you like to work on it, move it to any host, license it to others, or sell it along with your business. Nobody can take it away or charge you for continued use.
• A license — you have permission to use software someone else owns. The terms define everything: how long, how many users, on what hardware, at what recurring cost. A perpetual license is real value, but it is not ownership, and the terms end where the document ends.
• Source code access — you can see and hold a copy of the code. On its own, this says nothing about what you are allowed to do with it. Access to code you have no license to modify is a filing cabinet you cannot open.

The combination that leaves you stuck is the common one: a license to use, no ownership, and no source code. The developer holds everything. Your business runs on software you cannot inspect, cannot change, and cannot take with you. If that developer raises prices, gets slow to respond, or goes out of business, you have no move to make. The application that runs your scheduling and your invoicing is somebody else’s asset.

What about the open-source pieces?

Here is where owners sometimes overcorrect. Every modern application is built partly on open-source components — the framework, the database driver, the PDF generator, dozens of small libraries. Nobody owns those outright, including your developer, and you should not expect to.

That does not undercut your ownership. You own the application built for you: the business logic, the workflows, the data model, the interface — the part that is actually specific to how your company works. The open-source pieces come in under their own licenses, and the overwhelming majority use permissive terms like MIT or Apache that allow commercial use without restriction.

The thing worth asking about is whether anything in the stack carries a license that conflicts with your plans. Some open-source licenses impose obligations if you redistribute the software. For most small businesses running an internal tool, this never comes up. If you intend to resell your software as a product someday, it matters a great deal, and it is worth saying so during scoping. Ask for a list of third-party components and their licenses. Any competent developer can produce one quickly.

The parts people forget: accounts, data, and the domain

Owning the code is only part of controlling your software. Projects get built on a pile of accounts and services, and whoever’s name those are in has real leverage. This is the quiet failure mode — the contract handles the copyright perfectly and the business still can’t move without help.

• The hosting account should be in your company name, with your billing on it. If it is on your developer's account, your application lives inside their infrastructure.
• The domain registration should be yours. Domains registered by an agency on a client's behalf are a recurring source of ugly disputes.
• The code repository should be under your organization, with your developer given access — not the reverse.
• Your data is yours, and you should be able to export it in a usable format on request, without a fee and without a negotiation.
• Third-party API keys and service accounts — payment processing, email delivery, mapping — should be registered to your business.

None of this is hostile toward your developer. It is just the difference between renting and owning. A good development partner sets it up this way from day one, because they are planning to earn the ongoing relationship rather than lock it in.

What to look for in the contract

You do not need to become a lawyer. You need to find the intellectual property section and check that it does a few specific things:

• It assigns "all right, title, and interest" in the deliverables to you, rather than merely granting you a license to use them.
• The assignment happens on delivery or on final payment — and the trigger is stated plainly, so you know exactly when ownership lands.
• It commits to delivering the source code, not just a running application.
• It identifies anything the developer is keeping — most firms retain rights to their general-purpose internal tools and libraries — and grants you a perpetual license to whatever of that is embedded in your software.
• It says nothing that conditions your continued use of the software on continued payment for support or hosting.

That fourth point deserves a note, because it is legitimate and it surprises people. Most experienced firms have accumulated internal libraries they reuse across clients. They are not going to assign you exclusive ownership of a utility that also runs in forty other applications, and you would not want to pay what that would cost. What you want instead is a perpetual, irrevocable license to that piece — so your software keeps working forever regardless of what happens between you and them. A developer who is straightforward about this distinction is being honest with you, not hedging.

If a firm resists putting ownership in writing, that answer is the information you came for. There may be a reasonable business model behind it — some products are legitimately sold as subscriptions and never transfer ownership at all. That can be a fine deal. It just isn’t custom software you own, and it should not be priced like it is.

Why this matters more than it seems

The ownership question feels abstract while everything is going well. It becomes concrete in four situations, and every one of them is a situation you might actually land in.

You want to switch developers, because the relationship soured or your original developer moved on. You want to sell the business, and the buyer’s diligence asks who owns the systems the company runs on — a question that has sunk deals. Your developer goes out of business, and you need someone else to be able to pick up the work. Or you simply want to build something new on top of what you already have, and you need the freedom to do that without asking anyone.

In all four, ownership is what turns a bad week into a manageable one. The software you paid to have built should be an asset on your side of the ledger — something you can hand to any competent developer along with the keys. That is what you were buying.

How Kairos handles it

You own what we build for you. The code, the data, the accounts. It is assigned to you in writing, the source code is yours, and the hosting and domain go in your company’s name from the start. If you ever want to take the project to another developer, you can, and you will not need our cooperation to do it.

We would rather earn the ongoing relationship than hold your business hostage to it. After 20 years of building custom software, Brad Walker has seen the alternative arrangement plenty of times, and it does not produce better work. It produces clients who stay because they are stuck. That is a bad foundation for a partnership, and frankly it is a bad way to run a company.

If you are weighing a proposal from anyone — us or someone else — read the intellectual property section before you sign. It takes five minutes and it tells you most of what you need to know about who you are dealing with.

Frequently asked questions

If you are weighing a build and want the ownership terms spelled out before anything gets priced, start with a conversation. We will scope the work first, and what you own when it ships is not a negotiation.