Who Holds the Keys? A Founder's Handover Audit Before the Last Agency Invoice

There is a specific kind of silence that follows a successful app launch. The Slack channel goes quiet, the weekly calls stop, and then an invoice arrives with a cheerful "final payment due" at the bottom. Most founders pay it within the hour. It feels like closing a chapter.

Here is the less comfortable version: that invoice is the last piece of leverage you will ever have over your own product. Once it clears, the only thing standing between you and a fully owned app is how well the handover was done. And handover, in my experience of watching these things go sideways, is the part of the project nobody scoped properly.

So treat this as a product requirement, not admin. If you cannot rebuild, release and support the app without the people who built it, you do not own it. You are renting it, and the rent goes up whenever you need a change.

Start with the boring question: what did you actually buy?

Plenty of agency contracts describe "the deliverables" in glowing language and then fall silent on intellectual property. Under UK law, copyright in the code sits with the person who wrote it unless there is a written assignment. That is a genuinely awkward position to discover six months later when you are trying to raise a round and an investor's lawyer asks who owns the repository.

Before you sign anything off, check that the contract (or a short deed of assignment signed now) transfers the IP in the source code, designs, copy and any bespoke assets to your company — not to you personally, and not "on full payment" with no date attached. If the agency used open-source libraries, that is fine, but ask for a list and a note on licences. A GPL dependency buried in a payments flow is the sort of thing that surfaces at the worst possible time.

The repository is not the product

Founders often relax the moment they get access to GitHub. Good — but a repository without a working build pipeline is a museum piece. You want to be able to press a button and produce an app that ships.

Ask for, and test, all of the following:

• Full commit history, not a single squashed "initial commit"
• Access to the CI/CD setup — Bitrise, GitHub Actions, Codemagic, whatever it is — with you as an owner rather than a guest
• Environment files and how secrets are injected
• The iOS distribution certificate and provisioning profiles
• The Android keystore file, its alias and its password, stored somewhere you control
• Any Fastlane scripts or release notes templates the team used

That Android keystore deserves its own paragraph. Lose it and you cannot push an update to the same listing — you are starting again with a new app, a new package name and no reviews. Agencies do hand these over. Sometimes they hand them over late. Sometimes the password lives in the head of a developer who has since moved to Berlin. Get it in a password manager you own, today.

Store accounts: the ownership test that actually matters

Here is a simple question. Can you log in to App Store Connect and Google Play Console right now, without asking anyone, and see your app?

If the answer is no, stop reading and go fix that. Apple is strict about organisation accounts and transfers, and Google's process for moving an app between developer accounts is workable but not instant. Both involve waiting, and waiting is expensive when a critical bug is live.

Aim for the store accounts to be registered in your company's name from day one, with the agency added as a user with the permissions they need. If it is too late for that, get the transfer process started before the final invoice, not after.

The long tail of third-party accounts

This is where handovers quietly rot. Your app probably touches a dozen services, and each one has an owner email address. Analytics, crash reporting, push notifications, payments, email delivery, maps, SMS, customer support, feature flags, uptime monitoring, the domain and its DNS records.

If those accounts were created under [email protected], you do not control your own product's infrastructure. Insist on either a full transfer or new accounts created in your name and re-keyed. Then rotate every credential that has passed through anyone else's hands — API keys, webhooks, signing secrets, admin logins. Rotation is not paranoia; it is standard hygiene after any team change, and it costs an afternoon.

Design files and the things nobody lists

Figma files with edit access, not a flattened PDF. Brand assets, icon sets, font licences (check they cover app distribution, not just web). The copy deck. Any user research, accessibility notes or QA test scripts. It is remarkable how often a founder asks for a small change three months later and is told the original designer's files were on a laptop that has been wiped.

Contracts, VAT and the data question

Three bits of UK paperwork worth getting straight before the money moves.

The contract. Ask for a short handover schedule appended to the agreement, listing exactly what is being transferred and by when. Vague promises are not enforceable in practice.

The VAT invoice. Make sure the final invoice is a valid VAT invoice — the agency's VAT number, your company name, a sequential invoice number, the VAT rate and amount shown separately. If you are VAT-registered and reclaiming, a scribbled PDF with a total and no breakdown will cause your accountant to send you a deeply unimpressed email. Also confirm whether any final invoice includes a retention or support tail-off, and get that in writing.

The data. Under UK GDPR, if the agency processed personal data on your behalf, they were a processor and you were the controller. That means there should be a data processing agreement in place, and it should say what happens at the end of the engagement: return the data, then delete it. Ask for written confirmation that their copies — production database snapshots, staging environments, exported analytics, old backups — have been deleted. If a customer subject access request lands on your desk in eight months, you need to know exactly where their data lives. The ICO's guidance on controller and processor roles is a decent plain-English starting point if you need to push back on a supplier who insists it is all too complicated.

A printable pre-payment checklist

Print this. Work through it with the agency on a call. Do not pay until every box is ticked or has a dated commitment attached.

• IP assignment signed and filed
• Repository access with full history, you as owner
• CI/CD access confirmed and one successful build triggered by your team
• iOS certificate and provisioning profiles in your possession
• Android keystore, alias and password secured
• App Store Connect and Play Console access tested by you, logged in, no assistance
• All third-party service accounts transferred or recreated in your name
• Credentials rotated after the handover call
• Domain, DNS and email sending records under your control
• Figma and brand assets with edit access
• Data processing agreement plus written deletion confirmation
• Valid VAT invoice with full breakdown
• A named contact and a defined support window for the next 30 days

The 30-day window is not a formality

Ask for a short post-handover support period — 30 days is reasonable — during which the agency answers questions at no extra charge. Use it. Get your own developer to deploy a minor change to a staging build in week one. You will learn more about the state of the codebase in that single exercise than in any assurance email.

Handover is not the epilogue to an app project. It is the bit that decides whether you have a product or a dependency. Pay the invoice once you hold the keys — not before.