Who Owns the Code? IP, Repos and Handover

"You own the code" is in almost every agency contract, and it is almost always true. It is also almost never the thing that decides whether you can actually do anything with the code on the day you need to.

Ownership is a clause. Access is an account. The clause assigns the rights; the account determines whether anyone at your company can push, deploy, rotate a key or move the repository. Those two can be true at once and still leave you stuck, and the gap between them only becomes visible at the worst possible moment.

Start in the right place and the question disappears

The whole problem is created by a default: the agency creates the repository in its own organisation because that is where its tooling already is. Everything after that is recovery.

The alternative costs nothing at the start. Create the repository in your organisation and add the agency as collaborators. Same for the hosting account, the analytics property, the error tracker and the domain. The agency gets access; you keep the account. Nothing about the work changes, and the handover stops being an event.

Where this is not possible — an agency with a genuinely shared toolchain, say — the fallback is to agree the transfer date in the contract rather than at the end. A date that exists is a date that gets met.

What a repository transfer actually moves

If you are recovering rather than starting clean, it helps to know what a transfer does. GitHub's documentation on transferring a repository is specific, and the list is better than most people assume.

Transfers with the repository:

"When you transfer a repository, its issues, pull requests, wiki, stars, and watchers are also transferred."

"Git information about commits, including contributions, is preserved."

"If the transferred repository contains webhooks, services, secrets, or deploy keys, they will remain associated after the transfer is complete."

"All links to the previous repository location are automatically redirected to the new location."

Does not follow along:

"We don't redirect GitHub Pages associated with the repository."

And moving from an organization to a personal account, "the repository's read-only collaborators will not be transferred." Issue assignments can also be cleared depending on the direction.

None of that breaks the code. All of it breaks something somebody was relying on — a documentation site, a reviewer's access, an assignment queue. A transfer needs a checklist, not a click.

The sentence that matters in a dispute

GitHub requires "administrator access to the repository" to initiate a transfer, and for an organization repository, "owner permissions in an organization or admin permissions to one of its repositories."

Read that as a risk statement. If nobody at your company holds admin on the repository, you cannot move it yourself — regardless of what the contract says about who owns the intellectual property. You would be asking the other party to perform an action only they can perform, at a moment when your relationship with them has already broken down.

That is the practical definition of lock-in, and it is created by a setup decision rather than by a contract term.

The same logic, applied to everything else

Repositories are the clearest case, not the only one.

• The domain. The hardest to recover, because it is the one with statutory waiting periods. ICANN's transfer policy lets a registrar refuse a transfer within 60 days of registration, within 60 days of a previous transfer, and after a change of registrant — we set out the order of operations in the domain and DNS guide.
• Hosting and deployment. Rebuildable, but the environment variables are not, and they are usually in one person's terminal history.
• Analytics. A property created by an agency takes your historical data with it. Create it yourself.
• Third-party accounts. Payment provider, email sender, SMS gateway, error tracker. Each one is a login that either belongs to you or does not.
• The design files. Ownership of a rendered site is not ownership of the source file that produced it.

What a real handover contains

A handover is not a zip file. The version worth writing into a contract:

1. Admin on the repository, the hosting account and every third-party account, in your organisation's name.
2. The domain in your name as registrant, with your own email on the registrar account.
3. Environment variables and secrets documented somewhere durable — not in a chat message, and not only in a deployment platform's UI.
4. A README that gets a new developer running locally, tested by someone who has not worked on the project.
5. Deployment steps written down, including how to roll back.
6. A support window with a stated end date, in which questions are still answered.

If that list is not in the contract, it gets assembled under time pressure by the person who is leaving, which is the worst possible combination of motivation and deadline.

Where we say no

We do not hold client repositories, domains or accounts. We ask for access to what we need and we hand back what we made — the terms are part of the contract discussion, not a favour at the end. The rest of the cross-border paperwork is in working with a US agency.

We do not treat a handover as a milestone to be invoiced separately. If a client cannot run the thing we built, it is not finished, and calling the missing half a service is a way of charging twice.

And we will not build on tooling a client cannot own. If the only way to maintain a site is through a licence in our name, we have sold a dependency rather than a website — which is the same objection we raise about managing a client's domain.

The five-minute check on your current project

1. Open the repository. Whose organisation is it in, and does anyone at your company have admin?
2. Look up your domain's registrant. Not the registrar — the registrant.
3. Ask where the environment variables are documented. If the answer is a person, that is the risk. The same risk applies to a freelancer or a single in-house developer; we compare the three models in agency vs freelancer vs in-house. Why that kind of key-person dependency is common at small software firms is explained in how to choose a software development company.
4. Try the README on a clean machine. Or ask someone to, and time it.
5. Check the analytics property owner. Historical data does not move if the account does not.

If you would rather have these answered in writing before a project starts than discovered when it ends, ask us for the handover terms up front — they are the same either way, which is the point. How these terms fit with the rest of the way we work is set out in what is Caliency.