Who Actually Owns Your App? The Handover Evidence UK Buyers Should Demand
Photo: mobile app handover documentation folder laptop UK office, via profit.pakistantoday.com.pk
Most app handovers do not fail because the agency is malicious. They fail because the handover was never scoped. The code gets passed over, maybe a repository invite lands, and everyone shakes hands. Six months later the client discovers the push certificates sit in a personal Apple account, the CI pipeline runs on a founder’s credit card, and the mapping bill is tied to an agency email address nobody can access.
That is not a handover. It is a dependency with a nice folder icon.
Treat handover as a procurement requirement
If you are buying a kitchen, you expect the building regulations certificate, the appliance manuals and the warranty details. An app is no different. The handover pack should be written into the statement of work before the first sprint, with a named owner and a clear acceptance test. A polite promise at the end of the project is not enough.
The useful question is simple: if the agency disappeared tomorrow, could your team keep the app running, release a fix and move to a new supplier without begging for access? If the answer is no, you do not own the app. You are renting it.
What belongs in the handover folder
A zip file of source code is the bare minimum, and often not even that.
Source code and history
You need the full repository, not a snapshot. That means commit history, branches, tags and merge records. Ask for read access during the build and admin rights at handover. Check that the repository sits under an organisation your business controls, not a personal GitHub or Bitbucket account. Confirm the licence for every third-party library and that no code depends on an agency-internal package that is not included.
Signing keys and store accounts
This is where the exit tax usually starts. Apple Developer Program and Google Play Console accounts should be owned by your company, with agency staff added as users. You need signing certificates, provisioning profiles, push notification keys, App Store Connect API keys and Google Play service account credentials. The same goes for any enterprise distribution or test flight setup. If the agency insists on holding the keys ‘for security’, ask who is securing whom.
Pipelines, environments and secrets
A modern app is more than code. It has CI/CD workflows, build scripts, environment variables, database migrations and hosting configuration. Get the pipeline definitions, the list of secrets and where they live, plus a working build from a clean machine. If the build only works on one developer’s laptop, it is not a build process. It is a magic trick.
Third-party services
List every external service and who owns the billing and admin rights: analytics, crash reporting, authentication, payments, maps, SMS, email, push, content delivery, monitoring and any AI or search APIs. Transfer ownership or create company-owned accounts. Export historical data where the contract allows it. Watch for services registered under an agency email address, because password resets become hostage negotiations.
Exit documentation
Ask for an architecture diagram, API inventory, data model, release runbook, support process and a short video walkthrough of the deployment. Documentation does not need to be a novel. It needs to answer the questions a new developer will ask in week one.
The pre-sign-off test
Do not wait for the final invoice. Run a handover rehearsal four to six weeks before launch. A person who did not build the app should try to clone the repository, install dependencies, run the test suite, build a release candidate and deploy to a staging environment using only the handover folder. If they get stuck, the folder is incomplete.
Then test the boring but critical access: can your finance team see the cloud bill? Can your marketing lead access the store listing? Can your security contact rotate a key? Can someone remove an agency user without breaking the build?
Put it in the contract
The strongest handover clause is specific. It names the assets, the access levels, the format and the deadline. It ties final payment to a successful handover test. It states that all accounts, domains, certificates and repositories must be owned by the client. It also says what happens to agency-held credentials after the project ends.
None of this is adversarial. Good agencies will welcome it, because it forces clarity early. The ones that resist are telling you something useful.
The cost of finding out late
The exit tax is rarely one big bill. It is a series of small, annoying costs: a rushed security audit, a consultant rebuilding a pipeline, a delayed release because nobody can renew a certificate, a legal review of account ownership. The total is often larger than the original handover would have been.
So ask for the folder. Check it while the agency is still motivated to help. And remember that ownership is not a feeling. It is a set of credentials, documents and access rights that your team can actually use.