What You Own When a Project Ends

12 August 2026 · 4 min read

blog contents
  1. Accounts in your name, from day one
  2. Code a stranger can run
  3. The parts that are not code
  4. A window where questions still get answers
  5. What a good handover actually looks like
  6. The clause worth writing down
  7. What to check before the final payment

read

Handover is the clause nobody reads until they need it. A complete one is four things: source code in a repository you control, accounts and domains registered to you, documentation a new developer can start from, and a period where the previous team still answers questions. If any of the four is missing, you are renting your own product.

Accounts in your name, from day one

The hosting, the domain, the analytics, the ad accounts and the store listings should be registered to you and shared with the agency, never the other way round.

This costs nothing at the start and is close to impossible to unwind later. An agency that registered your domain on its own card is holding something you cannot simply take back.

Code a stranger can run

A repository is not a handover. A handover is a repository with a readme that says how to run the thing locally, how it reaches production, and what has to be configured before it will start at all.

The test is worth running before the final invoice: give the repository to a developer who has never seen it. Whatever they have to ask about is the documentation you are missing.

  • How to run it on a fresh machine
  • How a change reaches production
  • Which settings and keys are required, and where they live
  • What is deliberately unfinished, and why

The parts that are not code

Design files, the copy that was written, the ad creative, the translation memory. All of it was paid for and all of it is routinely left behind.

Translation is forgotten most often. If the strings live only in the agency tooling, the next language costs full price again instead of building on what already exists.

A window where questions still get answers

The last useful clause is time. A month in which the people who built it still reply turns a handover from a folder into a transfer.

Without it you get a complete archive and nobody who remembers why any of it was done that way.

What a good handover actually looks like

The best version is not a document delivered at the end. It is a repository that has been yours the whole time, with the agency working inside it as a contributor.

When that is the arrangement, handover stops being an event. There is nothing to transfer because nothing was ever held anywhere else, and the final month is spent on questions rather than on packaging.

The clause worth writing down

A workable version fits in a paragraph. On completion or termination, for any reason, the client receives administrative access to the repository, the hosting, the domains and every third party account created for the project, together with the documentation needed to run and deploy the system.

Add the support window and a date by which all of it happens. Naming a deadline is what turns the clause from a principle into an obligation.

What to check before the final payment

Withholding a final instalment until handover is verified is normal practice and rarely contested by a team that intended to comply.

The check is short and worth doing while there is still leverage.

  • Log in to every account yourself, from your own device
  • Confirm your name on the domain registration, not the agency's
  • Have someone outside the project run the code from the repository
  • Read the deployment instructions and follow them once

questions

When should handover be agreed?

Before the first line of code. It is a cheap conversation at the start and an expensive one at the end, because by the end one side holds all the leverage and no reason to give it up.

Is a repository enough?

No. Code without instructions is an archive, not a working system. The measure is whether a developer who has never seen the project can get it running from what you were handed.

What if the agency refuses?

That is useful information while you can still act on it. A team confident in its work has little reason to withhold the means to leave, because clients who can leave easily mostly do not.

More on this track

  1. Build or Buy, Decided Before Anyone Codes Build when the process is the thing you compete on. Buy when the process is ordinary and you have just never standardised it. Most requests for custom software are really requests to avoid changing how the company works, which is the most expensive possible reason to build anything. The honest test: could a competitor copy your workflow from a screenshot and gain nothing? 28 July 2026 · 2 min read
  2. Translation Is Not Localisation Translation swaps the words. Localisation changes the assumptions underneath them: currencies, name and address formats, dates, reading direction, what counts as polite, and which examples make sense at all. A perfectly translated page can still feel foreign, and that feeling costs conversions long before anyone can name why. The parts that break are rarely the sentences. 9 July 2026 · 2 min read
  3. Why Your MVP Keeps Growing An MVP grows because nobody wrote down what it was for. Without a single task it has to support, every request sounds equally reasonable and the honest answer to each one is yes. The fix is not discipline, it is a definition: name the one task a real user must be able to finish, then judge every request by whether that task works without it. 24 June 2026 · 2 min read