Make a Paid App Free on Google Play: Sales vs Promo Codes

Google Play documents three ways to let people install a paid app for nothing: a temporary $0 sale, a promo code, and the permanent switch that makes the app free for good. Only one of the three is a one-way door, and it is the one most guides tell you to click first. Two of them also carry caps that decide whether your promotion is even possible this month. A sale runs from one day to fourteen and then stops on its own, and a second sale cannot start until thirty days after the first one ends.

The three documented routes, and which one cannot be undone

The short answer: if you want the app free for a fixed window, run a $0 sale. If you want specific people to get it free while everyone else still pays, issue promo codes. If you want the price to be zero from now on, use the free switch and accept that you can never charge for that package name again.

Each route is a different tool with a different ceiling, and the ceilings are where developers get caught. A launch promotion that runs longer than fourteen days is not possible as a sale, no matter how the console is configured. A reviewer giveaway for eight hundred people is not possible with a single quarter's promo-code allowance. And a "temporary" free period set through the price field is not temporary at all.

If the deeper question is whether a one-time price is the right model for the app at all, our breakdown of the seven Android monetisation models covers where a paid price beats subscriptions and where it loses, which decides how much a free window is worth running.

What you want	Mechanism	Hard limit	Reversible
Free for everyone, short window	$0 sale	1 to 14 days, then a 30-day gap	Yes, reverts on the end date
Free for named people only	Promo codes	500 non-subscription codes per quarter	Yes, codes expire
Cheaper, not free	Percentage or fixed-price sale	10% minimum discount, 14 days maximum	Yes
Free from now on	Make your app free	Permanent, package-wide	No

Step 1: the sale lives under App pricing, not under the price field

Sales sit in Play Console under Monetize with Play > Products > App pricing, on the Sales tab. The price field on the same page is a separate control that changes the list price itself, and it is not a promotion. Confusing the two is the single most expensive mistake in this workflow, because one reverts and the other does not.

Google also retired pricing templates, which is why some older walkthroughs no longer match what you see in the console: "Starting October 27th, 2025, you'll no longer be able to manage prices across your products using pricing templates." Every price adjustment is now made at the individual product level, or through the onetimeproducts service if you manage prices in bulk. If a guide tells you to edit a template and push it to products, it was written before that change.

What a sale can and cannot do

The rules below come from Google's "Create sales for paid apps" page. They are not flexible, and several of them are only discoverable after you have filled in the form.

Rule	What Google documents
Eligible products	Paid apps only. Sales cannot be created for subscriptions or in-app products.
Discount types	Fixed price, or a percentage between 10% and 100%
Minimum discount	At least 10% off the full price in every impacted country
Length	Minimum 1 day, maximum 14 days
Gap before the next sale	30 days between the end date of one sale and the start date of another, per app
Scheduling window	Start date can be set to the next day; end date no more than 360 days in the future
Editing a live sale	Start date and price are locked once the sale begins. You can Stop or Resume it.
App state	The app must be published before a sale can be created or edited
$0 sale coverage	Setting the price to 0 applies a zero price across all regions automatically

That last row corrects a widespread instruction. Because a $0 sale applies globally on its own, there is no country list to tick for a free promotion; the region selector matters for percentage and fixed-price sales, where a discount applies only to the countries you select.

The 30-day gap is what actually breaks promotion calendars

For each app, 30 days must pass between the end date of one sale and the start date of the next. A sale that ends on 14 November cannot be followed by another before mid-December. Sample campaigns, seasonal pushes and "one more weekend" extensions all collide with that rule, and the console will simply refuse the second sale with no obvious explanation of why.

Plan the year backwards. If you have four dates you care about, each needs its own 14-day window plus a 30-day buffer behind it, which is roughly 44 days per promotion. Three promotions fit comfortably in a year; a monthly sale schedule does not. The clock is also per app rather than per account, so a second app in the same developer account runs its own schedule and is not blocked by the first one's cooldown.

The second half of the rule is that price and start date freeze the moment a sale goes live. Google's wording is that "if a sale has already begun, the start date and price can no longer be changed," with Stop and Resume as the only controls. Practically, that means a typo in the sale price cannot be corrected in place. Our reading is that stopping a sale ends it for the purposes of the 30-day gap, but Google does not state that explicitly, so we would not build a launch plan that depends on it.

A $0 sale is not a purchase, and your finance reports will show it

Google is explicit about the reporting side effect: "$0 sales don't count as purchases. As a result, the number of buyers in your reports may drop during a sale." The Finance Overview buyers table drops to zero, and the Buyers report and User Acquisition report both shift their buyer counts for the duration.

This matters because it is easy to read that as a demand collapse. If you are measuring a promotion week by buyer count, the number will look like the worst week you have ever had at exactly the moment installs spike. Judge a $0 sale on installs, retention and post-sale conversion to a paid tier, and treat buyer metrics as unavailable for the window.

There is a second documented cost. While a $0 sale is live, "your app won't be featured on any paid Top Charts during the time the sale is live." If chart placement in a paid category is part of your discovery strategy, a free window removes exactly the signal you were counting on.

In 13 countries the discount is invisible

Strikethrough pricing does not apply everywhere. In Belgium, Croatia, the Czech Republic, Denmark, Estonia, France, Greece, Hungary, Latvia, the Netherlands, Poland, Sweden and the United Kingdom, buyers see the discounted price with no reference to the original. Outside those markets, the saving is shown as a strikethrough over the full price.

So a sale in those thirteen countries is a silent price cut. If the promotion depends on the buyer noticing a discount, the creative and the announcement have to do that work, because the store listing will not. Google also tells developers to check promotion timing against local consumer protection law, which is a real consideration for anything framed as a limited-time offer in the EU and UK.

Promo codes: the route for named users

Promo codes are the only documented way to make the app free for a specific set of people while everyone else still pays. They work for paid apps, and the paid-app case is simpler than the in-app case: Google's instructions send you straight to the setup step for paid apps, while subscriptions and one-time products require In-app Promotions integration in the app first.

The limits are tighter than most launch plans assume. You can create up to 500 promo codes per quarter across all non-subscription promotions in an app, and paid-app codes share that pool with one-time-product codes. Google's own examples show the trade-off: 500 paid-app codes, or 250 paid-app codes plus 250 codes for one product, or 100 codes across five products. Codes created for subscriptions sit outside that pool.

Other constraints worth knowing before you promise anyone a code:

• Promotions can run for up to one year, and codes are redeemable until the end date you set.
• Unused codes do not carry over; if you do not use the quarter's allowance, you lose it.
• Once a promotion exists, you cannot change the number of codes in it or convert it to a different promotion type.
• Custom multi-use codes are available for subscriptions only. Paid-app promotions use one-time-use codes.
• Codes can be redeemed through a deep link in the form https://play.google.com/redeem?code=YOUR_CODE, which spares users from typing them in.

The practical consequence is that a 500-code quarter is a budget, not a tap. Spend it on the audience most likely to convert later, such as reviewers, community moderators or a small cohort of high-intent users, and keep the paid-app codes separate from in-app giveaways so the pool does not vanish in one campaign.

The permanent switch, and what it actually costs

The price page offers "Make your app free" next to the current paid status. Google describes the consequence in one direction only: "You can change your app from paid to free. Once your app has been offered for free, the app can't be changed to paid. If you want to charge for the app, you need to create a new app with a new package name and set a price."

That is the whole decision. There is no grace period, no rollback window and no exception route. Reversing it means a new package name, a new store listing, a fresh install history and a fresh set of reviews, with no continuity between the two apps. For an app that is being retired as a paid product, that is fine. For a launch promotion, it is the single most expensive way to run a free week.

The reassuring half is that the sale route does not carry this risk at all. Google states that a $0 sale "is temporary and is not the same as permanently offering your app for free" and that "creating a $0 sale does not impact your ability to charge for the app in the future."

If the app has not shipped yet, the sale is blocked

A sale cannot be created or edited until the app is published, so a launch-day promotion has to clear review first. If the plan is "free for the first week," the clock starts after the release goes live, not after you upload the bundle. How much lead time that review actually needs is covered in our measured review-timing breakdown. Our recommendation is to schedule nothing until the production release is available to users, then set the sale start date one day out.

Price changes also take time to propagate. Google notes that after you publish an app or update, including price changes, "it can take a few hours for your changes to be shown on Google Play." A sale that starts and ends within a single day leaves very little room for that delay, which is another argument for the 14-day window rather than a 24-hour flash promotion.

If the app is still in testing, the same rules apply

Testers install through the ordinary Play flow, and nothing in Google's testing documentation exempts a paid app from its price for testers. If you want testers to install without paying, the free sale or a promo code is the documented route, not the test track itself. License testing is a different feature: it removes the charge for in-app purchases during testing, and it does not change what a paid app costs to install. The setup for that is in our license-testing walkthrough, which is worth reading alongside this if the app also sells in-app items.

What we would do, in order

1. Decide reversibility first. If the answer is "free for now, maybe paid later," the sale is the only safe mechanism.
2. Check the calendar for the 30-day gap before committing to any date, then work backwards from the last promotion.
3. Confirm the app is published and that the base price is where you want it, since the 10% floor is calculated against the current full price.
4. Set the sale start date at least one day ahead so price propagation has landed before anyone is told about it.
5. Use $0 rather than a 99% discount when the goal is a genuinely free install; there is no country list to select and it reverts automatically.
6. Write the announcement yourself for the thirteen markets where no strikethrough appears, because the listing will not advertise the saving there.
7. Measure installs and post-sale conversion, not buyer counts, for the length of the window.

Frequently Asked Questions

Can I make my paid app free for a few days and still charge later?

Yes, using a $0 sale rather than the free/paid switch. Google states that a $0 sale is temporary and does not affect your ability to charge for the app in the future. The switch on the pricing page is the irreversible option; the sale on the Sales tab is not.

How long can a Google Play sale on a paid app last?

Between one day and fourteen days. Google documents a one-day minimum and a fourteen-day maximum, with the start date settable to the next day and the end date no more than 360 days in the future. Many third-party guides quote shorter caps; the documented ceiling is fourteen days.

Can I run two sales back to back?

Not immediately. For each app, 30 days must pass between the end date of one sale and the start date of another. Plan roughly 44 days per promotion once the discount window and the gap are added together.

Can I issue a promo code for a paid app?

Yes. Paid apps support one-time-use promo codes, and the setup does not require the In-app Promotions integration that subscriptions and one-time products need. Paid-app codes count against the 500-per-quarter non-subscription allowance for the app.

Do $0 sales count as purchases in my reports?

No. Google states that $0 sales do not count as purchases, so the Finance Overview buyers table can drop to zero during the sale and the Buyers and User Acquisition reports shift accordingly. Use install and retention data to judge the promotion instead.

Can I edit the price after a sale has started?

No. Once a sale has begun, the start date and price are locked; Stop and Resume are the available controls. Set the price correctly at creation time, because correcting it afterwards means ending the sale.

Will buyers see the discount in every country?

No. In twelve EU member states and the United Kingdom, buyers see the discounted price without a strikethrough or any reference to the original price. Everywhere else the discount appears as a strikethrough over the full price.

Does making the app free permanently stop me charging for it ever again?

For that package name, yes. Google states that once an app has been offered for free it cannot be changed to paid, and that charging for it again requires a new app with a new package name and a price.

Sources

• Google Play Console Help, "Create sales for paid apps". support.google.com/googleplay/android-developer/answer/7271135 (read 1 November 2026). Source for sale length, the 30-day gap, the 10% floor, $0 sale behaviour, strikethrough rules and editing limits.
• Google Play Console Help, "Set up your app's prices". support.google.com/googleplay/android-developer/answer/6334373 (read 1 November 2026). Source for the paid-to-free one-way rule, the pricing-template retirement and price propagation timing.
• Google Play Console Help, "Create promotions". support.google.com/googleplay/android-developer/answer/6321495 (read 1 November 2026). Source for the 500-code quarterly allowance, promotion duration, code types and redemption.
• Android Developers, "Promo codes". developer.android.com/google/play/billing/promo (read 1 November 2026). Source for redemption links and the subscription versus one-time-product differences.