US | Ownership | 2026-08-29

App Ownership: Source Code, Accounts, and What Handoff Should Include

Full source code is only part of it: the repository, store accounts, signing keys, backend project and secrets all need to end up in your name.

Two years after launch you move the app to a new developer, or the agency that built it stops replying, and you find the App Store listing sits under their company name and the Android signing key is on a laptop nobody has opened since the build. A routine version bump is now a legal conversation.

This is a common expensive surprise in small-business app projects, and it has nothing to do with code quality. The build can be excellent and you can still be locked out of your own product. Ownership is an administrative problem, cheap to solve at kickoff and painful to solve later.

What "you'll get the source code" usually leaves out

Source code is the part everyone remembers to ask for, and it is genuinely the foundation. Our own white-label Flutter builds ship in roughly 30 to 60 days from around $2,500 with full source code included, and we think that should be the floor rather than a selling point. But a repository on its own does not let you publish an update.

To ship version 1.1 without the original team, you need the code, the account the app is published under, the key it is signed with, the backend it talks to, and the credentials for every paid service it calls. Missing any one of those stops the release. So the useful question at contract stage is not "do I get the code" but "on the day this relationship ends, what can I do alone?"

The things that should sit in your name from day one

Not at handoff. From the first week, because retro-fitting ownership means transfers, and transfers have conditions.

• The Git repository, with full commit history, in an organisation your company controls
• An Apple Developer Program membership and a Google Play developer account under your legal entity
• Signing credentials: the Android keystore or Play App Signing enrolment, and Apple certificates tied to your account
• The backend: your Firebase or cloud project, on your billing account
• The domain and DNS, at a registrar you log into
• Analytics, crash reporting and any dashboard the app reports into
• Design source files, not just exported images, plus the licences for fonts and icons
• Every third-party account the app depends on: mapping, payments, SMS, email delivery, push

Create these under a role address such as a developer address at your own domain rather than a founder's personal mailbox, and put two-factor authentication on a company-controlled phone number or a shared authenticator. Founders leave. Personal Gmail accounts get deactivated. Neither should be able to strand a product.

Store accounts in the agency's name: the one that costs most to unwind

If your app is published under a developer's account, you control neither your listing, your reviews and ratings history, nor the ability to push an emergency fix. You cannot see your own sales reports properly either, and on Apple the payouts route to their bank details.

Both platforms support transferring an app between accounts, but neither is a button you press casually. Apple's transfer requires the receiving account to accept, and certain capabilities and agreements have historically blocked transfers until they are unwound. Google's process typically requires details from the original account registration, and both accounts must be in good standing. The conditions on both platforms change, so verify the current rules before you rely on them.

The other friction is registration itself. An organisation account on either platform needs a verified legal entity, and on Apple that means a D-U-N-S number for your business, which is free but can take days to obtain. Start it in week one of the project, not in week seven when the build is ready to submit.

The Android keystore, and the loss with no support ticket

Android apps are signed with a key. If your app enrolled in Play App Signing, Google holds the app signing key and you hold an upload key, which can be reset through Play Console support if it goes missing. That is the recoverable case, and it is why enrolment matters.

Older apps that self-sign are the dangerous case. Lose that keystore or its password and you cannot publish another update to that listing, ever. The only route forward is a new package name and a new listing: existing users keep an app that will never update again and must find and install a fresh one by hand, while your install base and review history restart at zero. Ask your developer in writing which situation you are in, and store the keystore and its passwords in your own password manager the day it is created.

Apple's side is more forgiving. Distribution certificates and provisioning profiles can be regenerated whenever you control the account, so the account is the asset to protect, along with any App Store Connect API keys used by build automation.

A repository with history, not a zip file on a shared drive

A folder of final files is not a handoff. You want the repository itself, commit history intact, in a GitHub, GitLab or Bitbucket organisation your company owns, with the agency added as members rather than owners. History matters more than founders expect: when a bug surfaces eighteen months later, seeing when a line changed and what shipped alongside it is often the fastest route to a fix.

Ask for the build configuration too, not just the app code. Continuous integration definitions, fastlane or equivalent release scripts, environment files and the exact toolchain versions used to produce the released binary should be in the repository or documented beside it.

Secrets and environment configuration, moved without emailing them

API keys, service account files, push notification credentials and payment provider secrets should never arrive as a message in Slack or a spreadsheet attachment. Move them through a shared password manager vault, and treat the handoff as the moment to rotate anything the outgoing team has held. If a key ever appeared in a commit, in a support ticket or in a screenshot, assume it is compromised and reissue it.

Ask for a list of every environment the app runs in, which keys belong to which, and which are billable. Plenty of businesses find their live app still calling a mapping or SMS account funded by a card about to expire.

Documentation somebody can actually start from

A one-line README is a stub, not a deliverable. What a new developer needs on their first Monday is a document that lets them build a release binary without contacting anyone: exact Flutter, Xcode and JDK versions, setup steps, where configuration files live, how to run the app against each environment, and the commands that produce a signed build for each store.

Add an architecture overview of a page or two, a list of known issues and deliberate shortcuts, and an inventory of accounts with who holds each. Honest notes on what was deferred are worth more than polished prose that hides it.

The dependencies and licences you are inheriting

Every Flutter app pulls in third-party packages and you inherit all of them. Ask for the dependency list with licences, and flag anything under a strong copyleft licence, since those terms can create obligations you did not intend commercially. Most common packages are permissive, but the review takes an hour.

Weigh maintenance risk too. A package with one maintainer and no release in two years is a future migration. Note commercial SDKs with their own contracts and usage pricing, because those bills follow the app whoever built it.

The checklist to run before the final payment

Hold a meaningful portion of the fee against a handoff you have verified yourself:

1. You are Account Holder on both store accounts, and you logged in to confirm it
2. The repository is in your organisation and you can revoke the agency's access
3. Keystore or Play App Signing status confirmed in writing, credentials in your vault
4. Backend project and billing sit under your entity, with you as owner
5. Domain, DNS and deep-link configuration verified in your registrar account
6. Every third-party account listed, transferred and rotated
7. An unrelated developer built a release binary from a clean machine using only the documentation
8. Design sources and font licences delivered and transferable

That seventh item is the real test. Everything else can look complete on paper and still fail it.

Settle this in the contract, not at the end

Put ownership in the agreement at kickoff: intellectual property assigns to you on payment, deliverables are itemised rather than called "the app", accounts are created in your name from the start, code lands continuously in your repository instead of arriving in one drop, and a transition support window follows final delivery.

None of this is adversarial. A studio that expects to keep working with you loses nothing by it, and one that resists has told you something useful. If you are weighing a build, we will walk through the ownership terms before anything is signed: see the overview, the blog, or get in touch.