Who owns the code, and everything around it
What to settle before the work starts, on one page.
Ownership follows the agreement, not the invoice. Ask for written assignment of what was made for you, a license you can live with for anything reused, and your name on every account it runs in. The accounts matter more than the code, because that is what a handover actually turns on.
Work it out in a minute
Four numbers and one question about fit. Gives you the answer and what it is worth.
What we take on
Paying for it is not the same as owning it
Without a written assignment, work made by an outside party can stay with whoever made it, and you hold a license to use it. That is a normal arrangement. It is only a problem when nobody said so.
Assignment for the bespoke part
The code written specifically for you should transfer to you in writing, on payment, named in the agreement. That is one clause and it is the one worth reading twice.
A license for the reusable part
Any builder worth hiring reuses their own components, and open-source libraries are in everything. Ask what is reused and on what terms. A broad perpetual license for those parts is ordinary and workable.
The accounts are the real handover
Domain, hosting, repository, database, payment gateway, analytics, mail. If those are in your name with you as owner, a change of builder is an afternoon. If they are not, the code alone will not help you.
Ask what a handover includes
Repository access, a written runbook, environment variables and where they live, how to deploy, and who to call about the domain. Agree that list at the start, when it costs nothing.
None of this needs to be adversarial
It is a short conversation at the beginning that removes a long one later. A builder who answers it plainly is telling you something useful about how the rest will go.
What to settle, and when
Settle it before the work starts. Every one of these is a sentence at the beginning and a negotiation at the end, and the end is exactly when the relationship is under the most strain.
The agreement should name three things: what transfers to you and when, what is licensed rather than transferred and on what terms, and who holds each account the thing runs in. Everything else is detail.
Reuse is not a red flag. A builder with a library of their own components delivers faster and cheaper than one starting from nothing every time, and open-source libraries sit inside every project either way. What matters is that it is written down.
The accounts are underrated and they decide more than the code does. A repository you can read, a domain in your name, hosting you can log into and a payment gateway you own is the difference between changing builders in a week and rebuilding.
Ask what handover looks like while everybody is still pleased with each other. A written runbook, deployment steps, where the secrets live and who to call. A builder who has thought about it will answer in a minute.
Where a lawyer writes the agreement, these are the points to hand them. Where one does not, the same points still belong in the email that confirms the engagement, because a written answer you both have is what an argument needs later.
Questions we get
We paid for it. Is it not automatically ours?
Not necessarily, and it depends on the agreement and the jurisdiction. In a lot of arrangements the person who wrote it keeps it and the client gets a license, which is fine when it is deliberate.
Written assignment is what removes the doubt. Ask a lawyer to draft it; that part is their work, not ours.
Is reusing their own components a problem?
No, and it is usually to your benefit. Ask what is reused and on what license. Broad, perpetual, no per-seat charge, no expiry is the shape to look for.
What is worth avoiding is a component you cannot keep using if the relationship ends.
Which accounts should be in our name?
Domain, DNS, hosting, repository, database, payment gateway, analytics, and the mailbox everything sends from. You as owner, the builder invited in.
This is the single most useful thing on the page. Everything else is recoverable; a domain in somebody else's account is not, quickly.
What should a handover actually contain?
Repository access, a written runbook covering deploy and rollback, the list of environment variables and where they are stored, any third-party accounts, and a named contact for the domain.
Agree the list at the start. Requested at the end it reads as a demand; agreed at the beginning it reads as a plan.
Is this legal advice?
No. This is what to ask for and why it matters. The agreement itself should be drafted or reviewed by a lawyer, and the clause about assignment is short enough that reviewing it is cheap.
What we do is the operating side: making sure the accounts, the runbook and the access match what the agreement says.
How do you handle it here?
What we build for you is yours, and it runs in your accounts under your logins from the first day rather than at the end. The handover document exists while the work is happening, not after it.
That is the arrangement whether or not anybody asks for it.
More in the guides and every answer in one place.
Shaheer leads the work, with engineers, writers, filers and analysts behind him. C-suite operations for a San Francisco AI company, Six Sigma on the process side, Anthropic certified on the Model Context Protocol, ten years across eight industries. See what we have built