Who owns the code? What to demand from a dev shop

Ask for the code to be assigned to you in the contract, and for the repository, the hosting account, the domain and every third-party account to be in your name from the first day. If any of those are held by the agency "for convenience", you do not own the result yet; you are renting it.

This post is a checklist for people buying a website, app or online store. It is not legal advice. Laws differ by country, so have a lawyer read the final contract.

Do I own the code just because I paid for it?

No, not by default. As one example, the US Copyright Office explains that when an independent contractor creates a work, the contractor generally owns the copyright unless a written agreement says otherwise. A work can count as "made for hire" only if there is a signed written agreement and the work falls into one of a short list of categories, and a transfer of ownership must be in signed writing. Other countries have their own rules, and the safe approach is the same everywhere: put it in writing.

Two separate questions hide in "ownership":

1. Who holds the rights to the custom code, design and content written for you.
2. Who controls access to the systems the site runs on: repository, server, domain, accounts.

You need both. A contract that assigns you the copyright, with the code sitting in the agency's private repository on the agency's server, leaves you dependent in practice.

What should be in my name from day one?

The rule is simple: you hold the accounts, and the agency is invited into them. Not the other way round.

• Repository. The code lives in an account or organisation you own, and the agency is a collaborator. If it was started in the agency's account, GitHub's transfer feature moves the repository with its issues, pull requests, releases and history, as long as the person transferring has admin access. Ask for this rather than a zip file.
• Domain. Register it in your own name as the registrant. ICANN's guidance tells registrants to register domains in their own names and keep contact details current, because the registrant carries responsibility for the registration.
• DNS. The DNS account (where the records are managed) is yours too. Whoever controls DNS controls where the website and your email point.
• Hosting or server. The cloud or VPS account is under your billing and your login. You may give the agency admin rights, but you hold the owner role.
• Third-party services. Email sending, analytics, payment provider, search, maps, error tracking, file storage: each has an account, and each account should be yours.
• Backups. Know where they are, who can restore them, and have a copy somewhere you control.

What about API keys, licences and third-party software?

Secrets and licences are where handovers quietly fail. Ask for:

1. A list of every API key and secret the project uses, what service each belongs to, and who owns that service account. Keys should be generated under your accounts, not the agency's. They should be stored in environment settings, never committed into the code.
2. A list of open source dependencies and their licences. An MIT licence, as an example, allows you to use, modify, distribute and sublicense the software, including in commercial projects, as long as the copyright notice and licence text stay with it. Other licences have stricter conditions. The agency should tell you if anything in your project has terms that restrict commercial use or require you to publish your own code.
3. Paid licences in your name. Fonts, themes, plugins, stock images and paid libraries should be bought under your licence, not the agency's, or you need a written statement that they transfer.
4. A statement about reused code. If the agency reuses its own components across clients, the contract should say what you get: a licence to use them in your project, perpetually, even if you part ways.
5. A statement about AI-generated code. If AI tools were used, ask that the contract say the agency stands behind the deliverable as if it had been written by hand, and that every line has been reviewed.

What documentation and handover should I get?

Handover is not an email with a password. A reasonable handover package has:

• A README that lets a new developer run the project locally in under an afternoon.
• A description of the environments (staging and production), where they are hosted, and how a release is deployed.
• The backup and restore procedure, tested at least once.
• The list of accounts, keys and services from the sections above.
• A short architecture note: what the main parts are and why.
• A walk-through session, recorded if possible, with you or your next developer.
• A list of known issues and open decisions.

Ask for the handover to be a scheduled deliverable with a date, not an extra you need to chase.

What exit terms should the contract have?

Plan the break-up on the day you plan the relationship. Look for:

• What happens if either side ends the contract, and with what notice.
• That all your accounts and code remain accessible to you during any dispute.
• A handover period after termination, with a defined scope and hourly rate if it is paid.
• That the agency does not have to approve the transfer of your domain, hosting or repository, and does not keep your data.
• That unpaid fees can be pursued, but cannot be used to hold the site hostage. This one is negotiable, and an honest agency will tell you where it draws the line.

Copy-paste checklist

Send this to any agency you are considering and ask for a yes or no on each line:

1. The code is in a repository owned by us. You are a collaborator.
2. The copyright in custom work is assigned to us in the contract (on payment).
3. The domain is registered in our name.
4. We hold the DNS account.
5. We hold the hosting or server account as owner.
6. Every third-party service account is ours.
7. All API keys were generated under our accounts and are stored outside the code.
8. You will give us a list of dependencies and licences, and flag any that restrict us.
9. Paid licences are bought in our name.
10. Terms for your reusable components are stated in the contract.
11. Documentation and a handover session are scheduled deliverables.
12. Backups exist, we know where, and a restore was tested.
13. Exit terms and a handover period are written down.

Contract wording to ask for

Use these as a starting point for your lawyer, not as final text:

• "Upon payment of the fees due, the Supplier assigns to the Client all rights in the custom deliverables, including source code, design and content created for the Client."
• "Pre-existing Supplier components used in the deliverables are licensed to the Client on a perpetual, worldwide, non-exclusive basis for use with the deliverables."
• "All accounts, domains and credentials relating to the deliverables are registered in the Client's name. The Supplier holds access only as the Client's delegate."
• "The Supplier will provide a complete list of third-party services, keys and software licences, and will notify the Client before adding any component whose licence restricts commercial use."
• "On request and on termination the Supplier will deliver the source code, documentation and a handover session within [number] business days."
• "The Supplier will not withhold access to the Client's accounts, domain or repository during a fee dispute."

When this is not for you

If you are buying a hosted site builder subscription, you are renting, and that is a fair choice for a small site; none of this applies except the domain. If you only need a quick prototype to test an idea, full ownership paperwork may cost more than the prototype. And if a very small budget forces you to use the agency's own platform, ask what leaving costs, and decide with that in mind.

Next step

SquadLoad clients own their code. If you want to talk through your own ownership checklist before you sign with anyone, including us, book a free call with Kevin. See our website development service, or go to contact.