Who owns the software when you pay someone to build it?

Most business owners we meet assume that if they paid for a piece of software, they own it. That's a fair assumption to make, and it's wrong often enough that the contract deserves twenty minutes of your time before you sign.

Most developers are perfectly reasonable people. You check the contract so that if the relationship ever ends, for whatever reason, your business can keep running without needing anyone's permission.

Paying for it and owning it are two separate things

Under US copyright law, whoever writes the code owns it by default, not whoever paid for it. Ownership only moves to you if the contract says so in writing. The phrase "work made for hire" is often used for this, but on its own it doesn't reliably transfer software written by an outside company. What you want is a clear sentence that assigns the copyright to you.

Plenty of firms do that. Others give you a license to use software they still own, which is a very different deal, and the contract won't usually point it out.

Three things to read carefully

First, look for ownership that only transfers "upon final payment." It sounds fair, but think about when it matters. If you ever end up in a disagreement over the last invoice, you also end up not owning the system your business runs on until it's settled. That's a weak position to be in.

Second, ask about tools and building blocks the firm brings with them. Most developers reuse their own components from project to project, and that's one reason they can work quickly. That's fine, but you should know how much of your system is made of their parts and what you're allowed to do with them. If a large share of it belongs to them, say a third, another developer can't simply pick it up. Ask for the answer in writing, as a list.

Third, watch for a license that's written to sound like ownership. A "perpetual, worldwide, royalty-free license" is generous wording, but it still isn't ownership. You usually can't sell it or pass it on if you sell the business, and the terms can be argued over later.

A simple test that matters more than the legal wording

Ask yourself this: if we parted ways on Friday, could a new developer pick the system up on Monday?

Whether you can usually comes down to who holds the keys, more than to anything in the copyright clause. Four things decide it. The code should be stored in an account your company owns, with the developer invited in, not the other way round. The hosting account, the website domain and the database should be in your company's name and billed to you. There should be written instructions good enough for a competent stranger to keep the system running. And the passwords and access keys the system depends on shouldn't live only in one person's head or password manager.

A firm that gets those four right has already given you most of what the contract is about.

Why escrow doesn't solve it

Sometimes a vendor offers source code escrow as a middle ground: a copy of the code is held by a third party and released to you if the vendor goes out of business. It sounds reassuring. In practice the release conditions are narrow, the copy is often months out of date, and what you finally receive is a folder of files with no hosting, no passwords and no instructions.

Escrow also only helps if the vendor disappears. It doesn't help if they're simply hard to work with, which is far more common.

What to ask for

You don't need a lawyer to improve your position, though it never hurts. Ask for four sentences in the agreement: the copyright in custom work becomes yours as it's written, not when the last invoice is paid; any of the firm's own components are listed by name and licensed to you permanently; your company holds the code and all the hosting accounts from the start; and if the relationship ends, the firm hands over instructions good enough for someone else to run the system.

If a firm pushes back on any of those, that tells you something worth knowing. We put all four in writing as part of how we work, so leaving us is always straightforward. We'd rather keep clients because the work is good than because they're stuck.