Who owns the code when you hire a development shop?

Almost every business owner we talk to assumes that paying for software means owning it. It is a reasonable assumption. It is also wrong often enough that it is worth twenty minutes with the contract before you sign.

Paying for it and owning it are different things

Under US copyright law, whoever writes the code owns it by default. Not whoever paid. Ownership moves to you only if the contract says so in writing, and "work made for hire" language alone does not reliably do it for software commissioned from an independent contractor. What you need is an explicit assignment of copyright.

Plenty of shops do assign it. Plenty of others hand you a license to use software they continue to own, which is a very different arrangement, and the contract rarely draws attention to the difference.

Three clauses that quietly keep it

1. Assignment contingent on payment

"Ownership transfers upon receipt of final payment" sounds fair. In practice it means that during a dispute, when you most need leverage, you own nothing. Any argument about the last invoice is also an argument about whether you can keep running your own business software.

2. Retained pre-existing IP

Most shops carry a framework, a component library, a set of internal tools. Reasonable, and it is usually why they can move fast. The question is what proportion of your system is that framework, and what you're licensed to do with it. A codebase that is 30% retained IP is not a codebase you can hand to another developer.

Ask for the answer in writing, as a percentage and a list.

3. A license dressed as ownership

"Perpetual, worldwide, royalty-free license" is generous phrasing for something that is not ownership. You cannot sell it, you often cannot sublicense it to an acquirer, and the terms can be argued about later. Ownership is one word and it does not need four adjectives.

The practical test

Forget the legal language for a moment and ask one question. If this relationship ended on Friday, could a developer you hired on Monday pick it up?

That question has almost nothing to do with copyright and almost everything to do with access. Four things decide it:

• The repository is in your account. Not theirs with you invited. Yours, with them invited. The difference shows up the day you fall out.
• The infrastructure is in your name. The hosting account, the domain, the database, the DNS. If the bill comes to them, so does the control.
• Documentation exists. Enough that someone competent can deploy it without a phone call. This is the one most often missing.
• The secrets are recoverable. API keys, certificates, service accounts. You would be surprised how often these live in one person's password manager.

A shop that gets all four right has already handed you the thing the contract is arguing about.

Source code escrow is not the answer

Escrow gets proposed as a compromise: the code sits with a third party and is released to you if the vendor goes under. It sounds like protection. In practice the release conditions are narrow, the deposited copy is often months stale, and what you eventually receive is a zip file with no infrastructure, no credentials and no documentation.

Escrow protects against the vendor disappearing. It does nothing about the vendor simply becoming difficult, which is the far more common problem.

What to ask for

You don't need a lawyer to improve your position here. You need four sentences in the agreement:

• Copyright in all custom work assigns to the client on creation, not on final payment.
• Any retained pre-existing IP is listed by name, and is licensed perpetually and irrevocably.
• The client holds the repository and all infrastructure accounts throughout.
• On termination, the vendor provides documentation sufficient for a competent third party to operate the system.

If a shop objects to any of those, the objection itself is the useful information. We put all four in writing, which is part of how we price rather than a concession we make at the end. The easier we make it for you to leave, the harder we have to work to make you want to stay.