Who Really Owns Your App? A Handover Checklist

A promise almost nobody breaks, and almost nobody keeps

Every agency page says you own the code. Ours does too. It is also close to meaningless on its own, because the repository is the cheapest thing to hand over and the least useful in isolation.

The real question is not *who owns the source*. It is: if this team disappeared on Monday, could another team ship version 1.1 by Friday? That answer depends on five things besides the repo.

1. The repository, with its history

A zip of the final state is not a handover. You want the git history — the branches, the commit messages, the pull request discussion. History is how the next engineer learns why a strange-looking workaround exists instead of deleting it and reintroducing the bug it fixed.

Ask for the repository to live in your organisation from the first commit, not to be transferred at the end. Transfers get forgotten; ownership from day one cannot.

2. The signing keys

This is the one that traps people. An Android app is bound to an upload key; lose it and you cannot ship an update to the same listing — the fix involves Google support, and it is not always available. iOS is more forgiving but a lost distribution certificate still costs days.

Ask: where is the keystore, who has the password, and is it in a place I control? If the answer is a laptop belonging to someone who no longer works on your project, you do not own your app.

3. The store accounts

The Apple Developer Program membership and the Google Play developer account should be registered to your company, with the agency invited in as a user. The reverse — your app living inside an agency's account — is the most common form of lock-in, and unwinding it means an app transfer, a review, and sometimes a lost listing history.

4. The backend and analytics projects

The Firebase project, the analytics property, the crash reporting, the remote config. Each holds data you will want and access you will need. A handover that stops at the code leaves the app running against infrastructure you cannot log into.

5. Build and release credentials

Automated pipelines are only an asset if they run for you. That means the CI configuration is in your repo, and the secrets it uses — API keys, service accounts, store credentials — are in your vault, documented, and rotatable without asking anyone.

6. The reason things are the way they are

The least tangible and the most valuable. Which decisions were deliberate, what was tried and rejected, where the sharp edges are. We write this as we go rather than as a leaving gift, because documentation assembled in the last week is a summary of what someone remembered, not a record of what happened.

What we do

Repository in the client's organisation from the first commit. Store and developer accounts in the client's name, us as invited users. Keys and secrets in the client's vault. CI configuration committed alongside the code. A knowledge base written during the build, not after it. And a full IP transfer signed as part of the contract — which is the paperwork that makes the other five enforceable.

None of this is generous. It is the minimum that makes "you own the code" mean anything, and it is worth asking about before you sign, not at handover.