With a live app, the risk is who can still sign in
A developer account with a published app carries a package name, signing setup, reviews and the ability to ship updates. What matters after handover is not whether the app is visible in search, but whether the previous owner, former contractors or old devices can still reach Play Console. Focus on who can sign in, by what means, and whether that access can be revoked, rather than on download counts alone.
Sign-in identity: email, recovery options and 2-step verification go together
The developer account sits on top of a Google account. Confirm three things: the login email can be transferred and its password changed; the recovery email and phone can be replaced with ones you control; and the 2-step method (SMS, authenticator or backup codes) can be reset during handover. If only the password changes while recovery options stay with the seller, they keep a path back in. The test is simple: after handover you should be able to change the password, reset 2-step verification and recover access without any action from the previous owner.
Past devices and sign-in environment: what can be checked and what cannot be promised
The Security page of a Google account shows signed-in devices and recent activity, which is the main place to review device history. Ask the seller where the account was used, then sign out old devices and remove third-party app access yourself after handover. Device records show login history only. They do not prove the account has no connection to other accounts, and nobody should promise that. If a seller is vague, or asks to keep one of their devices signed in, treat it as a failed handover condition.
Users and permissions in Play Console: who else is on the account
Under Users and permissions you can see invited members and their roles. Older accounts with apps often retain invitations for former developers, agencies or operators. Ask for a list of every email and role, have the owner remove anyone you do not need, and check for pending invitations, which take effect once accepted. If a member is the actual developer of the app, agree separately on source code and maintenance instead of assuming that removing access settles it.
App ownership materials: signing keys, package name and store listing
Being able to sign in does not guarantee you can keep updating the app. Check whether Play App Signing is enabled and whether the upload key can be reset or held by you. If the app uses a self-managed key held by the original developer, losing it can block updates. Also review the package name, privacy policy link, Data safety form, target API level, and any policy warnings or restricted status. These change over time, so rely on what Play Console shows at that moment rather than verbal descriptions.
Payments profile and payouts: confirm separately if the app earns revenue
If the app has paid features or in-app purchases, check who the payments profile, payout account and tax information belong to. These are often tied to the original registered entity and may not change with login access alone. Whether and how they can be changed depends on Google's help pages and console options at the time. If you only want to publish new apps, decide up front whether the existing payments profile needs to stay, to avoid unclear payout ownership later.
When to pause the order
Pause if any of these apply: the seller cannot explain how recovery options will be replaced; they want to keep their device or email access; Play Console shows users or invitations nobody can explain; the upload key is unrecoverable but the app still needs updates; or the account shows a restriction or violation that the seller cannot back with the actual notice. Sellers who can show screenshots, fields and explanations item by item are usually easier to work with on any follow-up issues too.