The premium for an app pays for the app, not the account age
An aged account and an account with an app are separate things. Account age gives you registration history. The extra price for an app corresponds to the app itself: its package name, store listing, ratings and reviews, install base and release history. If all you need is an account that can publish new apps, the app portion is money you did not need to spend. If you want an existing package name and its users, the account is just the container, and the app should be valued as the main asset.
Break the cost into five lines
A quote usually covers only the first line. The full cost includes the account price; the measurable value of the app (retained users, ratings, revenue); compliance cleanup (data safety form, privacy policy, target API level); handover work (signing keys, source code, assets, console permissions); and time (the app may be stuck while cleanup and the first update go through review). Convert the last four into hours or money and add them to the quote to get the true total. Fees and review times depend on the platform's current pages and the seller's written quote, so do not borrow someone else's numbers.
Signing keys and source code decide whether the app can keep shipping
Whether you can update the app depends on what you receive. If Play App Signing is enabled, Google holds the app signing key and the seller usually holds only an upload key, which can be reset through the console, so updates continue. If it is not enabled, you need the original keystore and its passwords; without them you cannot update that package name. Source code works the same way: without it the app can only sit there unchanged, with no way to fix bugs or adapt to new OS versions. Put the signing method, source delivery and timing in writing before ordering. A package name cannot be changed after publishing.
Check policy status before pricing the app
An app with history can carry liabilities. Ask the seller to show the policy status page, any violation or warning records, whether the data safety form is complete, whether the target API level meets current requirements, and whether the app has lost visibility from long inactivity. An app with open violations may cost more to fix than to rebuild, and the account-level risk rises with it. These requirements change every year, so rely on the platform's current developer policy pages.
Do not assume the app saves you the new-account hurdles
Some buyers treat an aged account with an app as a way around new-account requirements. That assumption needs care. Identity verification, closed-testing requirements for personal accounts and organization checks all follow the platform's current rules, and a published app does not by itself exempt later apps from them. Ask the seller what state the account is in, which requirements are already done, and whether a new app still goes through the full flow. Until you have a written answer, do not count the saved time as a benefit.
Three tests for whether it is worth it
Buy if the package name has users or revenue backed by console data, the total price is below what it would cost to rebuild an equivalent app and win similar users, the handover list covers signing and source, and the policy status is clean or the cleanup scope is clear. Stop if the seller cannot show app data in the console, cannot explain how ownership transfers, or the app has unresolved policy issues. If you really just need an account for new apps, buy one without an app and spend the budget on what you will actually use.