The most expensive decision in a mobile app project takes about four seconds, and it is usually made by someone who is not in the room.
You should own the developer accounts. The Apple Developer Program membership and the Google Play developer account both belong to your business, in your business name, with whoever builds the app added as a user on your accounts rather than publishing from theirs. Apple and Google both publish rules that land in the same place, and Google states it outright in a help document written for white label developers.
We have delivered 500+ projects across 30 countries. I have never met a client who regretted owning the account. I have met several who regretted the other version.
The store account is the one part of your app you cannot rebuild from source.
The mistake: treating the account as paperwork
Most buyers file the store account next to the hosting login. Something technical, handled by the technical person, sorted out later. Then the app ships and three facts arrive that were in nobody's proposal.
Your seller name is public. Apple's enrollment page says the name on the membership is displayed as the seller name of your apps on the App Store. Enroll as an individual and that is a person's full legal name. So if your developer enrolled as an individual and published your product, the name your customers see under it belongs to a stranger.
Google says the same thing in plainer language. Its best practices guide for white label developers notes that when every client app sits under one account, the developer account information shown on Google Play will be the same for all apps, and that clients who want to be fully branded away from the white label developer should use the separate account model instead.
And moving it afterwards is conditional. Apple does support app transfer, and it works well: the app keeps its reviews, its ratings and its Bundle ID, and users keep receiving updates through it. But the transfer criteria include a line that catches people. The app must have at least one version that was released to the App Store. An app that was built, submitted, rejected and never shipped cannot be transferred. It gets rebuilt and resubmitted from your account instead.
"Our developer handles the store accounts, they do this every week."
Somebody else is the seller of record on your listing, and untangling it depends on the app having shipped at least once.
"We enroll both accounts in week one. You get added as a user on ours."
Your business is the seller, your builder has the access they need, and nothing has to be moved later.
What Apple checks before you have an account at all
This is the part that sets your launch date more often than the code does, because Apple's organization enrollment is a verification process, not a checkout.
You need a D-U-N-S Number so Apple can verify your organization's identity, legal entity status and address. You need to be a legal entity that can enter into contracts with Apple, and Apple states directly that it does not accept DBAs, fictitious business names, trade names or branches. You need a work email address on your organization's own domain. And you need a website that is publicly available and functional on that domain, because Apple says links to social media pages, websites with minimal content, and pages showing a message from a domain registrar will not be accepted.
Membership is 99 USD per membership year. The fee has never been the problem. The problem is the business trading under a name that is not its registered entity name, or the founder whose entire web presence is one social profile, finding out in week six of a ten week build.
Google tells white label developers to split the accounts
Google publishes a best practices guide for white label developers, and it is worth reading even when you are the client, because it lays out exactly what your builder is choosing between on your behalf.
There are two models. Separate accounts, where each client has their own developer account that either they or the builder administers. Or one shared account, where every client app is published together. Google recommends the separate model and repeats the recommendation several times. Its stated reason is risk, not branding: under the shared model, policy issues with one app can negatively impact all other apps within the same account, which Google warns can lead to serious account level consequences including suspension or termination. It adds that repeated or severe violations can result in an account ban that removes every associated app and blocks future submissions.
Read that as the customer. In a shared account, whether your app stays downloadable depends partly on the policy behavior of other businesses you have never met.
Google has a second gate that has nothing to do with anyone's competence. Personal developer accounts created after 13 November 2023 must run a closed test with at least 12 testers opted in continuously for the last 14 days before they can apply for production access, and Google says that application review usually takes 7 days or less. Organization accounts sit on a different track. Under somebody's personal account, that is a two week clock plus a review before the production button exists.
One more rule, aimed squarely at template work. Apple's review guidelines state that apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app's content, and that those services should not submit apps on behalf of their clients. If someone is selling you a branded app built on a template, whose account it ships from is not a preference. It is the rule that decides whether it ships.
Three moves before anyone writes code
The bottom line
I have never seen an app project fail on the account question by itself. I have seen it add a month. I have seen a business work out, well after launch, that the listing its customers had been downloading was legally somebody else's.
Worth separating two projects that get quoted as one. A companion app for an existing business is a distribution problem, and everything above is the job. If the app is the product you sell, you are launching software, and the accounts are item one on a much longer list.
Getting it right at the start costs 99 USD and one afternoon of paperwork. Our AI mobile app builds ship in 3 to 10 weeks at fixed prices from $14,999, and account enrollment is item one on the plan rather than the last thing anyone remembers. Who I am, if you want the background first.
Book a 30 minute call: cal.com/zeeshanwaheed/30min or email [email protected]. Bring two things: the legal name of the entity that will own the app, and whether it already has a D-U-N-S Number. That is a five minute answer on the call.