US | Store accounts | 2026-08-29

Apple and Google Developer Accounts for First-Time Founders

Enrolment is the step founders leave until last and the one most likely to delay a launch. Here is what Apple and Google actually ask for, and when to start.

Most first-time founders treat the Apple and Google developer accounts as paperwork for the week the build is finished. Then the D-U-N-S lookup comes back empty, the bank details sit in a personal name, and a finished app waits on a laptop for three weeks while a verification email crawls through somebody's queue.

That delay is avoidable, and it is a common reason a project tracking to eight weeks ships in eleven. These accounts are not a signup form. They are the legal identity your company trades under on two stores that now both check who you claim to be.

The account is a legal identity, not a login

When someone taps your listing on the App Store or Google Play, the seller name they see comes from the developer account, not your app's branding. On an individual Apple account that is usually the enrolling person's own legal name. A founder who signed up personally because it was faster ends up with her own name printed under a product called Rivet Fleet Dispatch.

The problem runs past cosmetics. The entity on the account signs the store agreements, receives the payouts and files the tax forms. If that entity is a person rather than your company, the revenue lands in the wrong place and your accountant finds out later.

Individual or organisation: the choice that is hard to walk back

An individual account is quick. You sign in, pay, and enrolment often completes within a day or two. An organisation account asks for a registered legal entity, evidence that you have authority to bind it, a working company website, and a D-U-N-S number.

The temptation is obvious, and so is the trap. Moving from individual to organisation is not a toggle in settings. Apple handles it as a support request, and it can mean enrolling the company separately and transferring each app across, which requires the receiving account to be in good standing with its agreements already signed. Apps with certain entitlements or an active subscriber base make that transfer fussier still.

If there is any chance you will raise money, hire, sell the business, or add a second founder, enrol as the organisation from the start. The extra fortnight up front is cheaper than an app transfer during a growth month.

The D-U-N-S number decides your start date

A D-U-N-S number is a nine-digit business identifier issued by Dun & Bradstreet, and Apple requires one for organisation enrolment. Google Play now asks organisation accounts for one as well. It is free, and Apple runs a lookup tool that will find your existing number or start a request.

Two things surprise people. You may already have a number, issued via a bank or a supplier, and never have known. If you do not, a new one commonly takes several business days and can run longer in some countries. Then there is the detail that really burns the calendar: the company name, registered address and phone number on the D-U-N-S record must match your official registration and the enrolment form exactly. Put a trading name where the registered name belongs and the check fails without explaining why.

What the fees look like, roughly

Apple's developer programme is an annual membership, around a hundred US dollars a year at the time of writing, billed in local currency. Google Play charges a one-time registration fee in the region of twenty-five US dollars. Apple also runs a separate enterprise programme at a much higher annual price for internal distribution only, which almost no small business needs.

Treat those figures as orientation, not gospel. Both companies adjust pricing and regional amounts, and some non-profits and government bodies qualify for waived Apple fees, so check the published numbers before you budget. The money is trivial next to the real cost, which is time.

Google Play's verification and testing requirements

Google Play has tightened considerably. New accounts go through identity verification: government ID for an individual, matching legal entity, address and D-U-N-S details for an organisation. Existing accounts have been pulled through the same process in waves, and contact details must be verified because some of that information appears publicly.

The rule that catches people out applies to newer personal developer accounts: before a first app reaches production, Google expects a closed test running continuously for weeks, with a minimum number of opted-in testers on the order of a dozen real accounts. Organisation accounts are treated differently, which is one more reason for a business to enrol as one.

Both stores also require trader status information for European distribution under the EU's Digital Services Act, and those contact details appear on your listing. These rules change frequently. Verify anything you read, this page included, against the current developer policy pages.

Why the account must belong to your business, not your developer

Agencies and freelancers sometimes offer to publish under their own account. It reads as convenience. It is a hostage situation with good intentions.

If your app lives on someone else's account, they hold the listing, the reviews, the ratings history, the subscriber relationships and the signing keys. Ending the relationship means an app transfer they have to agree to, or a fresh listing starting at zero reviews. We ship full source code with every build for exactly this reason, and the accounts belong alongside it in your name. Add your studio as a user, then remove that access when the engagement ends. Talk to us if a contract reads loosely here.

Roles beat shared passwords

Both consoles support proper team management, and both get ignored in favour of one login in a password manager that four people share. That login is usually the Account Holder or Owner, the identity you should protect hardest.

• Create one account per person, with the narrowest role that lets them do their job.
• Keep the Account Holder or Owner with a founder or director, never a contractor or a departing employee.
• Give developers upload rights without financial or agreement permissions.
• Give your accountant finance access without release powers.
• Review the user list quarterly, and immediately after anyone leaves.

Agreements matter here too. When Apple publishes an updated paid applications agreement, only a narrow set of roles can accept it, in practice the Account Holder. If that person is unreachable, paid sales and in-app purchases stop until somebody signs.

Tax, banking and payouts before submission day

If you plan to charge anything, the money plumbing must be finished before your first paid release. On Apple's side that means accepting the paid applications agreement and completing the tax and banking sections in App Store Connect, with a bank account in the exact legal name on the account. On Google it means a payments profile, which carries its own verification and can ask for documents.

Mismatches stall everything. A bank account in a trading name. An entity name with a comma where your registration has none. Set an internal deadline two weeks before your target submission date and treat it as immovable.

Two-factor and a recovery plan you actually write down

Apple requires two-factor authentication on the account used for the developer programme, and Google effectively does the same. That is good security and a genuine single point of failure. If the Account Holder's phone is the only trusted device and that person is on a plane or no longer with the company, you cannot ship.

Register at least two trusted devices or phone numbers. Store recovery codes somewhere the company controls, not an individual's inbox. Use a shared company mailbox, with more than one person on it, as the account email. Then write down who may sign what and keep it with your governance documents.

A realistic timeline

Work backwards from the date you want to submit, not forwards from today.

1. Week one: confirm the exact registered entity name and address, check whether you already hold a D-U-N-S number, and request one if you do not.
2. Week two: D-U-N-S record confirmed and corrected if needed; company website live on a domain that matches the entity, because Apple looks at it.
3. Week three: submit Apple organisation enrolment, create the Google Play account, begin identity verification on both.
4. Week four: add team members with roles, complete tax and banking, accept agreements, configure two-factor and recovery.
5. Week five onward: reserve the app name, create the listing shell, and start closed testing if your Play account requires it.

Four to six weeks ahead of submission is a comfortable margin. We deliver white-label Flutter apps in roughly thirty to sixty days starting around $2,500, so account work should begin at kickoff, not handover. More build notes sit on our blog, or see what we make on the homepage.