Why the question matters before you start
At the start of an app project, accounts feel like an administrative detail. The development company offers to publish under its own developer account to save time, hosts the backend on its own cloud subscription and keeps the code in its own repository. Everything works, and nobody thinks about it again until the relationship changes.
Then the detail becomes the whole problem. The app's listing, with its users, ratings and reviews, sits in an account the business cannot enter. Updates cannot be published without a key somebody else holds. This guide sets out what the business should hold, what the development company needs, and how to arrange both from the first day.
What the business should hold
| Asset | Held by | Development company's access |
|---|---|---|
| Apple and Google developer accounts | The business, as an organization | Invited user with a suitable role |
| Store listings | The business's accounts | Can prepare and submit releases |
| Signing keys and certificates | The business, stored securely | Use through the build pipeline |
| Code repository | An organization account of the business | Contributors with write access |
| Cloud hosting and databases | The business's subscription | Roles limited to what the work needs |
| Third-party services | The business: payments, messaging, maps, analytics, crash reports | Team members added as users |
| Domains and email sending | The business | Records changed on request or by delegated access |
| Design files | A workspace of the business, or exported copies | Editors during the project |
The pattern is the same on every line: the business is the account holder and pays the bill, and people are added and removed as users. No shared passwords, and nothing in a personal account.
Developer accounts in the app stores
Each store ties an app to the developer account that published it. The name shown to users as the seller or developer comes from that account. If the development company publishes under its own account, the public sees the company's name, and the business has a listing it does not control.
- 01
Enrol as an organization
Both stores distinguish individual accounts from organization accounts. Enrolment as an organization involves verifying the legal entity, which can take time, so begin as soon as the project is agreed.
- 02
Use a shared company address
Register the account holder on an address such as a role mailbox that survives changes of staff, with a second person able to recover it.
- 03
Add at least two internal administrators
A single administrator who leaves, or loses a phone, can lock the business out.
- 04
Invite the development company with roles
Both stores let the account holder invite users with defined permissions. Give what the work needs and review the list regularly.
- 05
Keep legal and financial sections internal
Agreements, tax and banking details in the account are the business's own affair.
If an app already sits in a developer's account, both stores document a process for transferring it. Our guide on what to ask before taking over an existing app covers that situation.
Source code: access and rights are two questions
Access is practical. The code should live in a repository under the business's organization account from the first commit, with the full history, so that the business can read it, back it up and give another team access at any time.
Rights are legal. Who may use, change and resell the code depends on the contract and on the law that governs it. Ownership and licensing terms are defined in the project agreement, and a business should read those clauses with its legal adviser before signing, not after delivery.
- 01
What does the agreement say about custom code written for this project?
Why it mattersThis is the core question. Look for when rights pass, and whether that depends on payment.
- 02
Does the company reuse its own existing components?
Why it mattersMany do, reasonably. The agreement should say what licence the business receives for them and whether another team may maintain them.
- 03
Which open-source libraries are included?
Why it mattersTheir licences carry conditions. Ask for a list.
- 04
Are there paid components or services with their own terms?
Why it mattersLicences may be tied to an account or a number of users, and need to be in the business's name.
- 05
What is handed over if the relationship ends?
Why it mattersCode, keys, documentation and a period of cooperation should be described.
A worked example
Setting up accounts for a clinic's booking app
This example is invented to show a clean arrangement. A group of clinics commissions a patient booking app and wants to avoid depending on any one supplier.
- Before the contractThe clinic's lawyer reviews the clauses on rights to the code. The agreement states what the clinic receives for custom work and what licence covers the company's reusable components.
- First weekThe clinic enrols in both stores as an organization, using a role mailbox. Verification takes longer than hoped, which does no harm because development has only begun.
- SetupThe clinic creates an organization on a code hosting service and a cloud subscription, and invites the development team to both. The messaging and payment services are opened by the clinic's finance officer.
- During the projectThe team works entirely inside the clinic's accounts. Signing keys are generated there and used through the build pipeline, so no developer holds a private copy.
- Two years onThe clinic moves maintenance to an in-house developer. Access for the original team is removed in an afternoon, and nothing has to be transferred.
The change of supplier was an administrative task because the clinic held every account from the start. The development company lost nothing by working this way, and the clinic had no reason to worry during the project.
Common objections, and how to answer them
Reasonable requests from a developer
- Administrator-level roles during active development
- A named contact who can approve store agreements quickly
- Access to billing alerts for the cloud account
- Time in the plan for account verification
- A licence, not a transfer, for their reusable components
Arrangements to decline
- Publishing under the developer's own store account
- Code delivered only at the end of the project
- Hosting on the developer's subscription with no exit plan
- One shared login used by the whole team
- Keys kept only on a developer's laptop
A developer who resists client-held accounts is usually protecting convenience, and occasionally a hold over the client. In either case the answer is the same, and a professional company will accept it.
Ownership setup checklist
App accounts and code checklist
0 of 10 checkedWhat to do next
If you are about to start a project, begin the store enrolments now, since they take the longest. If your app is already live, list every asset in the table and write down who holds it today. Any line that names an outside company or a private individual is a task.
We work inside client-held accounts as a matter of course, and our mobile app development page explains the rest of how we run a project. Ask us about your setup if you would like a second view.
Common questions
Is it a problem if our app is published under the developer's account?
It works until you need to change developer, sell the business or settle a dispute. The listing, its reviews and the ability to publish updates are controlled by that account. Both stores document a transfer process, so the situation can usually be corrected. Arrange it while relations are good, since it needs the current account holder to act.
Does paying for development mean the code is ours?
Not automatically. The answer depends on your contract and on the law that applies to it, and the default position differs between countries. Some agreements pass rights on payment, some grant a licence, and some keep reusable components with the developer. Have the relevant clauses reviewed before you sign, and keep a copy with your project records.
What access does a development company legitimately need?
During active development, roles that let the team create builds, manage test users, prepare store listings and operate the hosting. They do not need to be the account holder, see your banking details or keep access after the engagement ends. Roles can be widened for a release and narrowed afterwards.
What are signing keys, and why do they matter?
They are cryptographic credentials that prove an update comes from the same publisher as the original app. The stores and the phones check them. If a key is lost, or held by someone who will not cooperate, publishing an update becomes difficult or impossible without a recovery process. Treat them like the deeds to a property.
We are a small business. Is this level of care necessary?
The steps are the same at any size and take a few hours in total. Small businesses are in fact more exposed, because they often rely on a single freelancer and a single internal contact. Holding your own accounts is the cheapest insurance available to you, and no reputable developer will object to it.
