What You Should Own at the End of an App Project
This is the seventh post in a series adapted from my guide, Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. Each entry takes one slice of the guide and turns it into something you can read in ten minutes.
One of the most common and avoidable problems in mobile development is a client discovering, after the relationship with a developer ends, that they don't actually own their own app. Not because anything fraudulent happened, but because nobody discussed ownership at the start, and the accounts, code, and credentials ended up in the developer's name by default.
Getting this right costs nothing at the beginning of a project. Fixing it afterward can be expensive, slow, and occasionally impossible. This post covers what you should own, why it matters, and when you need to have it.
The accounts you need to own
Several external accounts are created or used during the course of building a mobile app. Each one should be in your name, registered to your email address, and under your control before development begins. Not at the end. Before it starts.
Apple Developer account
This is the account that allows apps to be submitted to the App Store. It costs $99 per year and is tied to either an individual or an organization.
Use the organization (business) account, not the individual account. The cost is the same, but the organization account lets you invite team members and assign them specific roles without sharing your credentials or giving up control of the account. Your developer gets the access they need; you remain the account owner.
This matters for two reasons that go beyond access. First, any revenue generated by in-app purchases or subscriptions flows to the account owner. If your app is submitted under your developer's account, your revenue goes to them. Apple pays out to whoever owns the account. Second, the account controls what gets submitted to the store and what doesn't. You need that control to remain with you regardless of what happens with the developer relationship.
Create the Apple Developer account yourself at developer.apple.com before a single line of code is written. Add your developer as a team member with the appropriate role. The app should be registered and submitted under your account from the beginning, not transferred later.
Google Play Developer account
The Android equivalent. A $25 one-time fee, registered to you. Same principle: create it yourself, add the developer as a user with appropriate permissions.
Third-party service accounts
Most apps depend on external services: Firebase or AWS for the backend, RevenueCat for subscription management, Mixpanel or Amplitude for analytics, Stripe for payments, and so on. Each has its own account, its own billing, and its own data.
Every one of these accounts should be registered to you from the start. Your developer gets added with appropriate access, not the other way around. If you let the developer create these accounts under their own credentials, you may find yourself locked out of your own app's data if the relationship ends.
Make a list of every external service the app will use. Confirm you have owner-level access to each one before development begins.
The code repository
The source code is the primary investment you're making in this project. It needs to live in a repository that you own and control, with full administrative rights.
This is not the same as being granted access to a developer's repository. Access can be revoked. Permissions can be changed. A developer who controls the repository controls the codebase, even if they've nominally given you visibility into it.
The right setup: you create a repository under your own GitHub account or organization. Your developer is added as a collaborator. As work is completed and paid for, the code gets pushed to your repository. If the relationship ever needs to end, you remove the developer's access. Your code stays exactly where it has always been, fully under your control, with the complete commit history intact.
A developer who resists this setup is a significant red flag. The code you're paying for belongs to you. The repository it lives in should belong to you as well.
Own it as you pay for it
A common misconception is that ownership transfer is something that happens at the end of a project. It shouldn't be. As each piece of work is completed and paid for, it should already be in your possession: in your repository, in your accounts, under your control.
This matters because things happen. Developers become ill, unavailable, or simply unresponsive. Disputes arise. Relationships end before a project reaches its formal conclusion. If you've been paying for work that lives entirely in someone else's accounts and repositories, you may find yourself unable to access what you've already paid for.
Get the code into your repository from the start. Get access to your accounts from the start. By the time a project is complete, there should be very little to hand over because you've already been receiving it as it was built.
A final review at project completion is still valuable: confirm nothing has been missed, verify all credentials are current, make sure documentation is in order. But that final check should be confirmation of what you already have, not the first time you're asking for it.
The code itself
Ownership of the source code should be addressed explicitly in your contract. In many jurisdictions the default is that the person who wrote the code owns it, not the person who paid for it, unless a written agreement specifies otherwise. Make sure your contract includes a work-for-hire or IP assignment clause that transfers all ownership to you upon payment for each milestone.
If a developer raises a concern about this, ask specifically what they object to. A legitimate concern is pre-existing utility code or personal frameworks they use across projects. A reasonable solution is to carve that out separately: pre-existing code is licensed to your project, newly written code is yours outright. This is a standard arrangement and worth accepting. What isn't acceptable is a developer retaining ownership of code written specifically for your product.
What to confirm at delivery
At project completion, run a checklist against what you should already have:
- Source code in your repository, with full commit history
- All design files in their original editable format (Figma, Sketch, or similar), not just exported images
- Credentials and API keys for all third-party services, stored somewhere secure that you control
- Documentation sufficient for a new developer to understand the project structure
- Confirmation that all App Store submissions were made from your Apple Developer account
If any of these aren't already in your possession, resolve it before releasing final payment.
If you're already in a project and haven't done this
Raise it now. A professional developer handles this without friction. Most ownership gaps exist because nobody discussed it upfront, not because anyone was trying to take advantage.
For Apple, register the app under your own Apple Developer account using your own bundle ID. The developer works within your account going forward.
For third-party services, if the product isn't live yet, set up new accounts under your name, give the developer the access they need, and use your own API keys in the project from that point on.
For the code repository, ask your developer to push the full codebase and commit history to a repository you own. This is a standard git operation and takes minutes. Once it's there, work continues in your repository.
An awkward ten-minute conversation now is far better than an expensive problem later.
This post is adapted from Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. If you'd rather just talk it through, reach me at scott@appswage.com.