Can Two Developers Share One Google Play Console Account?

Yes, one Google Play developer account can have as many people working in it as you need. What it cannot have is two people using the same login. Google's own guidance for Play Console is explicit: "Keep the Play Console secure by using individual accounts to sign in instead of sharing login credentials." One person registers and owns the account; everyone else is invited by email, signs in with their own Google account, and receives only the permissions you grant them.

That distinction matters more than it first appears, because the developer account is not just a dashboard. It is the identity Google verifies, the entity that holds your closed test, and the recipient of the production access decision. Two-person teams are one of the most common shapes we see in our 1,500+ closed-testing campaigns, and the projects that stall on account questions almost always stalled on who owns what, not on testing itself.

This guide covers how to add a second developer properly, what each access level can and cannot do, what inviting someone changes about your 12-tester requirement, and what to do when a co-founder or client leaves. Every rule below is quoted from Google's Play Console documentation, and the operational observations are drawn from the campaigns we run rather than from forum advice.

What sharing a Play Console account actually means

Developers use the phrase "sharing my account" for two very different situations, and only one of them works.

Sharing a login means two people type the same email address and password. Google's team management guidance advises against it directly, and the operational problems are concrete: every action in the account is logged against one identity, access cannot be revoked from one person without changing the password for everyone, and the account is registered to a single verified person while multiple people act under that name.

Sharing an account properly means the account owner sends an invitation. The second developer signs in with their own Google account, sees only the apps and settings you allow, and appears as a separate row in the user table with their own status and, if you set one, their own expiry date. Removing them later is a single action that takes effect for them and only them.

The gap between the two versions shows up when something changes. In our campaign records, the two-person projects that get stuck are usually the ones where the account was registered in one founder's name with the other founder's password typed in from the same laptop. When that person becomes unreachable, or the partnership ends, there is no documented second user to promote and no clean way to hand over control. The invited-user version has an answer for both: promote the user to admin, or run the documented ownership transfer described later in this article.

The rest of this article is about the second version, because it is the only one Play Console is built for.

The three access levels in Play Console

Google documents three access levels, and "your access level determines what actions you can perform and what information you can access in Play Console."

Two details in that table shape most team decisions. First, the payments profile belongs to the owner alone, so if the app sells anything, the owner is the person whose financial identity is attached to the account. Second, admins and users cost nothing: the $25 fee is paid once by the owner, and everyone you invite afterwards pays nothing.

For a two-person team the usual split we see work is: the registered owner keeps the account, and the co-founder gets admin, so both of you can invite testers, upload builds and manage the store listing without either of you needing the other's password. For a contractor who only needs to upload release candidates, a user with "Release apps to testing tracks" and nothing else is enough, and an expiry date turns a one-off engagement into access that removes itself.

How to invite a second developer

Adding a user takes about a minute and needs nothing but their email address.

1. Open Play Console and go to the Users and permissions page.
2. Type the email address you want to invite. To give a time-limited access, set an access expiry date; if you skip it, "the user will have ongoing access to your Play Console account or app indefinitely."
3. Choose the permissions. Account permissions apply to every app in the account; App permissions apply only to the apps you select.
4. Select Invite user.

Three mechanics catch people out:

The email address is a lock, not a label. Google states that "invited users can only sign in to Play Console using the same email address that you provided." If your co-founder invited you at one address and you try to sign in with another, it will not work. They have to resend the invitation to the address you actually use. Invited users can sign in with a Gmail address or with an existing address such as a company email, and Google Workspace users can create a Google account on their company domain.

Invitations expire after 30 days. If the person "doesn't accept an invitation and sign in within 30 days, the invitation will expire and the admin will need to resend an invitation." Until they sign in, their row in the user table shows "Invite sent" and they have no access at all. When they accept, the account owner receives a confirmation email and the status changes to "Active."

Permissions are granular and revocable. The permission list includes view app information, manage store presence, release to production, release apps to testing tracks, manage testing tracks and edit tester lists, reply to reviews, view financial data, and delete or create draft apps, among others. You can grant one person the ability to upload builds and nothing else, or give your bookkeeper financial data and no release rights. You can also put users into permission groups so a change applies to several people at once, and you can set expiry dates on individual users or whole groups. If you have not registered the account yet, our developer account creation guide walks through the registration itself, including which identity details you will be asked to verify.

What inviting a developer changes about your 12-tester requirement

Short answer: nothing. The requirement counts apps and testers, not people with console access.

Google's testing requirement for new personal developer accounts states that developers "must run a closed test for their app with a minimum of 12 testers who have been opted in continuously for at least 14 days" before applying for production access. That number attaches to the app's closed test, and inviting a co-founder as an admin or user does not change it in either direction. For what else the requirement does and does not depend on, our 12-testers requirement guide covers the account-level details.

There is a related question underneath, which is whether the second developer can count as one of the twelve. A tester is a Google account that has opted in to your closed test, and a developer invited to your console has a Google account, so nothing in Google's documentation excludes them. Treat that as a weak slot rather than a free one, for two reasons. The production access application asks you to describe your testing process and summarise the feedback you collected, and a co-founder who opens their own app daily is thin evidence of real-world testing. And our campaign records show that Google's engagement checks are looking for genuine use, not account activity: in the 1,500+ closed-testing campaigns we have analysed, tests built on a handful of insiders plus real outside users are the pattern that survives review, while tests where most "testers" are insiders are the pattern that draws requests for more testing.

One practical note on mechanics, because it is where invites go wrong: the person who accepts your tester invitation must opt in with the same Google account you invited. In our records the most common silent failure in a two-person project is the developer adding a co-founder's personal address to the tester list while the co-founder installs the test build using their work Google account. The console shows an invitation that was never accepted, the opted-in count stalls at eleven, and the 14-day clock quietly never starts. Our guide to what counts as a closed tester covers the full set of conditions, and whether friends and family can fill the remaining slots covers what to do when your personal network has to carry the rest.

Who should own the account?

This is the decision that is expensive to reverse, and it deserves thought before you invite anyone.

The owner is a verified identity, not a placeholder. When you register, you link a Google Payments profile and verify the legal name and address that will be shown on Google Play. For an organization account you also provide a D-U-N-S number, organization name, address, phone and website; Google notes that "applying for a D-U-N-S number through Dun & Bradstreet is a completely free process." Identity verification is done by the owner, not by the people you invite.

The production access decision is addressed to the owner. After you apply for production access, Google reviews the application and "an email notification is sent to the account owner." Review "usually takes seven days or less." If a third party owns your account, the email about your app goes to someone else. Our production access application guide covers the application itself.

The payments profile follows the owner. The account owner is "the only person who can have a linked payments profile to sell paid apps." If you plan to charge for the app, the owner should be the party who should receive the money and sign the tax documents.

Practical recommendations, labelled as ours rather than Google's: when an agency or freelancer builds your app, register the account in your name and invite them as a user with release permissions, rather than letting them register it in theirs. When two co-founders start out, pick whoever will still be reachable in two years and whoever is comfortable being the verified identity, and write the choice down. Both are recommendations from how we see projects fail, not Google requirements.

When a co-founder leaves: two different kinds of transfer

Teams break up, clients change agencies, contractors move on. Play Console has two mechanisms, and confusing them costs you your testing work.

Changing who owns the account is possible without moving the app. Google's process lets the current owner hand ownership to another existing user: from Users and permissions, the owner selects the team member, chooses Make account owner, and the new owner completes a setup wizard that includes selecting a payments profile for identity verification. Two safeguards sit in the flow. The transfer "will be placed on hold for 7 days", during which any user on the account can cancel it; Google describes this as protection against "errors or unauthorized account hijack attempts." And eligibility is restricted: organization accounts and non-monetizing personal accounts may switch owners, but "individual developers who monetize their apps are currently ineligible for this direct transfer process" and must instead create a new account and transfer their apps to it. A transfer can also be blocked if the prospective owner already owns a separate Play Console account, or if the account has outstanding verification requirements.

Moving the app to a different account is the expensive one for a project in closed testing. In Google's app transfer documentation, "test groups (open, closed, internal test, and internal sharing) can't be transferred between accounts. You will need to recreate any closed testing groups in your new account, and users may need to opt-in to the test again." If you are on day 10 of a 14-day closed test and the app changes hands between accounts, the test is rebuilt from zero on the receiving account. If a breakup is likely, finish the test first, or change ownership of the account rather than moving the app. Our guide to what resets the 14-day clock lists the events that restart it.

Frequently asked questions

Can two developers share one Google Play account?

Not by sharing a login, which Google's own team management guidance advises against. Yes by invitation: one person owns the account, and the second developer signs in with their own Google account under permissions the owner grants.

Is it against Google's rules to share a Play Console password?

Google does not publish an outright ban on shared credentials. What it publishes is the opposite recommendation: "Keep the Play Console secure by using individual accounts to sign in instead of sharing login credentials." Beyond the security argument, a shared login removes the audit trail and makes clean revocation impossible.

Can there be two account owners?

No. The account owner is the first registered account and only one exists at a time. Ownership can be transferred to another existing user through a documented process with a 7-day hold, but it never duplicates.

Does adding a second developer reduce the 12 testers I need?

No. The requirement is per app: a closed test with a minimum of 12 testers opted in continuously for at least 14 days. The developer you invite can potentially be one of those testers if they opt in with their own Google account, but they do not reduce the number, and insider-only tests are weak evidence when you answer the production access questions.

How many people can I add to a developer account?

Google's documentation does not state a maximum. Permissions are set per person or per permission group, so you can add several people and grant each only what they need, with optional expiry dates.

What if the person I invited never accepts?

The invitation expires after 30 days and the admin has to send a new one. Until the person signs in with the invited address, their status stays at "Invite sent" and they have no access.

Do we need an organization account because there are two of us?

No. The choice between personal and organization accounts turns on whether you are operating as a registered business, not on headcount. Both types have the same functionality in Play Console. An organization account requires a D-U-N-S number and business verification, so if you go that route, start the registration early. See personal versus organization accounts for the full comparison, including what the choice means for the 12-tester rule.

Do closed testing groups transfer when an app moves to another account?

No. Google states that test groups cannot be transferred between accounts, that you must recreate closed testing groups on the receiving account, and that users may need to opt in again. Plan a transfer outside a running 14-day test wherever possible.

Sources

• Add developer account users and manage permissions - Play Console Help, access levels, invitation mechanics, permission definitions.
• Team and user management - Google Play Console, best practices including the guidance not to share login credentials.
• App testing requirements for new personal developer accounts - Play Console Help, the 12-tester 14-day requirement and the production access process.
• Choose a developer account type - Play Console Help, personal and organization accounts.
• Required information to create a Play Console developer account - Play Console Help, identity information and D-U-N-S numbers.
• Verify your developer identity information - Play Console Help, identity verification through the Google Payments profile.
• Transferring ownership of a Play Console developer account - Play Console Help, owner transfer process and eligibility.
• Transfer apps to a different developer account - Play Console Help, what transfers with an app and what does not.