Post-Launch Strategy: What to Do After Releasing

The short answer#

A post-launch strategy is four loops, run in this order: stabilize the build, talk to the players who showed up, read what the numbers say, then ship updates big enough to be worth discounting. The order matters, because each loop feeds the next. Calm reviews come from fixed builds, honest updates come from read data, and the first sale converts best when it rides a real content update. Somewhere in month one you also make the decision most indie developers avoid: how long this game gets your time before the next one does.

When	Loop	It is done when
Days 1–2	Stabilize	Crash reports falling, known-issues thread current
Weeks 1–2	Talk and read	Every review read, most answered, baseline compared
Weeks 2–4	Update	One patch shipped, one content update planned
Month 1+	Decide	Support window honored, decision day on the calendar

If you arrived here from the launch day checklist, this article picks up after item 30 closed the laptop.

What changes the day after#

Nothing about the game changed overnight. What changed is the direction of the work: before release you made things for the game, after release you make things for the people playing it. Players arrive over weeks, not in the launch spike. Store machinery — review queues, crash dashboards, refund windows — now runs on your game whether or not you watch it.

The first strategic act is a schedule, not a feature. Before reading a single review, write down your support window: two weeks of hotfix-level attention is the honest minimum, plus the date when you will decide between more content and the next game. Developers who skip this end up in support limbo, months of small fixes that please nobody, taken out of a game that is not growing and a next game that is not starting.

The first 48 hours: stabilize#

Triage reports by blast radius, the same rule as launch day: crashes hitting many players first, progression blockers second, typos never. What differs after launch is the machinery per store.

Store	A fix goes live	Your control
itch.io	Minutes after upload	None needed; there is no review step
Steam	Minutes after upload	Update post for followers; no direct review replies
Google Play	After review	Staged rollout by percentage, haltable
App Store	After review	Version goes live when review clears

Two of those rows deserve attention. Google Play's staged rollout exists for exactly this moment: an update reaches a percentage of users that you raise over time, and halting it stops the bleed if the fix itself misbehaves. One nuance from the documentation: staged rollouts work for updates only, not for a game's first release. And on Android, quality has numeric lines. Google defines bad behavior as at least 1.09 percent of daily users experiencing a user-perceived crash, or at least 0.47 percent hitting an app-not-responding error, with a separate 8 percent line for a single device model. Your aggregate can look healthy while one device model burns; the per-device view in Android Vitals is where that shows up.

On Steam the refund clock is part of stability. Buyers inside the 14-day, two-hour window can refund for any reason, and a patch that breaks saves converts quietly into refunds that never leave a review. Check the refund count the day after each patch, not just the crash thread.

Weeks one and two: talk and read#

Answer reviews where the store lets you. App Store and Google Play both allow developer replies, and one calm response to a two-star bug report (what broke, when the fix ships) reads better to every future visitor than fifty five-stars. On Steam you cannot reply directly; patch notes and the update post are the reply.

Read the numbers against your own baseline. You recorded day one: units, gross, refunds, review average, wishlists, traffic sources. The only useful comparison is this week against that baseline; industry averages are noise for a game with your traffic, your price and your niche. Three trends carry most of the signal: units per day, the review average as it accumulates, and for games with sessions, day-1 and day-7 retention against your own earlier weeks. If installs hold while retention drops, the game has a problem no store page can fix. If retention holds while installs decay, the store page and the update calendar are the levers.

Keep one public thread honest. The known-issues pin from launch week is now the game's unofficial support desk. A current list of what is broken, what is fixed and what ships next converts anger into patience better than any apology, and it doubles as the changelog when the update lands.

Updates that re-earn attention#

Fixes buy patience; content buys attention. On Steam, an update post lands in the feeds of everyone following your game, and the patch notes sit on the store page where a stranger weighing a purchase will read them. Valve's discounting documentation says outright what experienced developers do anyway: time discounts to content updates. A price cut on a stale build sells disappointment once and teaches buyers to wait forever.

Cadence is a judgment call, and slower beats faster. One update in the first month that visibly changes the game is worth more than four Fridays of minor fixes, because players judge updates by whether anything changed when they relaunched. On Google Play, ship the content update through a staged rollout too, and watch Android Vitals before widening the percentage. On the App Store, every update re-enters the review queue, so announce after the version is live (the same discipline as launch day). The mechanics of getting a build into each store are covered in the mobile publishing guide and the Steam Direct walkthrough.

Your first discount, without burning the game#

Steam's discount rules are strict and public, so plan the calendar instead of guessing:

• No discount for 30 days after release. The launch discount is the exception: 7 to 14 days, 10 to 15 percent suggested, 40 percent the ceiling.
• 30 days between any two discounts. This gap applies to every discount you run.
• Seasonal sales relax the gap rule, not the release rule. A game can discount within 30 days of a seasonal sale and still join it, but a game still inside its release cooldown cannot join a seasonal sale at all.

Valve's documentation works through the arithmetic in its own example: launch November 15 with a 7-day launch discount, the release cooldown clears December 15, and the Winter Sale opening December 17 is joinable. Nothing there is luck; it is arithmetic done at launch.

Two cautions from the same pages. Rushing into a 50 or 75 percent cut weeks after launch "sends a bad message" to the players who paid full price, and the deeper the early discount, the harder you train the market to wait. Let the first discount ride the content update from the previous section. Mobile has no direct equivalent of Steam sales; price work there is listing and experiment work, which is the App Store optimization guide's territory.

The listing is no longer frozen#

Post-launch you own something submission day never gave you: real conversion data. Both stores have machinery for acting on it. Google Play runs store listing experiments, up to three variants, text and graphics, on live traffic. Apple's product page optimization tests up to three visual treatments for up to 90 days. The moves that usually pay: replace the first screenshot with the mode players actually spend time in (not the menu you were proud of), and rewrite the description's first lines to answer the questions reviews actually ask. How to run those experiments is the ASO guide; the point here is timing. Post-launch is when that work starts, not when it ends.

Community and content after launch#

The community you built before launch is the distribution channel for update news: the same Discord, the same devlog readers, now with something concrete to talk about. Three habits keep it alive without becoming a second job.

Devlog the update, not the apology. A changelog is content when it shows a GIF of the fixed thing and a sentence on why it broke. "We fixed several issues" is neither content nor an apology.

Turn reviews into a public roadmap. Cluster the requests by how many reviews mention them, weight longer playtimes heavier, publish the top three, and say no to the rest with one line of reasoning. The loudest requester is rarely the median player.

Cut a post-launch trailer when the next sale needs one. The launch trailer promised; the post-launch cut proves. Real footage, the moment reviews keep quoting, the update that changed the game. The budget trailer guide covers the mechanics, and by now you have better material than you did then.

Patch, update, or move on#

Track	Effort	Goal	Choose it when
Hotfix window	Days	Stop the bleeding	Always, first two weeks
Content update	Weeks	Re-earn attention	Review average holding or climbing, retention solid
Expansion or DLC	Months	Monetize the core	Players asking for more of what exists
Next game	Quarters	Grow the audience	Both curves flat, and the new ideas pulling

Most indie games earn the bulk of lifetime revenue early and then decay, so the honest question in month one is which curve you are on. The update track compounds: existing players recommend the game they are still playing, and the next game inherits the wishlists, followers and reviewers this one earned. If the decision feels hard, that is exactly why it needs a date. "I decide on October 7" beats a support limbo that eats a quarter.

For games built for a longer tail, the same loops run deeper. Retention features like a proper save system and the choice of monetization model are their own articles, and picking the right store mix to begin with is the Steam, itch.io and Epic comparison.

Common mistakes#

Disappearing after week one. The known-issues thread dies, reviews go unanswered, and silence reads as abandonment to exactly the players most likely to defend the game.

Discounting a stale build. It breaks Valve's stated best practice and the buyers' trust in one move. The update comes first; the price cut rides it.

Arguing in review replies. You are writing to the thousand future readers of the thread, not to the angry reviewer, and they can tell the difference.

Roadmapping by volume. Feature requests from the loudest fans are not usage data. Weight them by how many players mention a thing and how long those players lasted.

Watching installs instead of retention. A player who stays is worth several who bounce; the games that grow post-launch are the ones people return to.

Never setting the decision date. Undecided support is the most expensive kind, because it spends your next game's calendar on this game's long tail.

How Egmatic fits#

Read this article again as a loop count: nearly every section ends with "get the fixed build onto every store." That loop is what we are building Egmatic to shrink. Egmatic is a no-code 2D editor and engine built on AI, currently pre-alpha: the editor hands a store-ready build to a publish layer, so a hotfix stops being an afternoon of console-hopping across Steam, itch.io and the mobile stores and becomes what it should be, minutes. The update loop you can afford is the update loop you will actually run, and the game you keep updating is the game that keeps selling. The current state is on egmatic.com; the waitlist there is how you watch that claim turn into a button.

Tomorrow morning#

Four items, in order. Read the new reviews with your coffee and answer two. Snapshot today's numbers next to the day-one baseline. Write the top three fixes by blast radius and ship the worst one. Then set the two dates, support window and decision day, because every other loop in this article runs on them. Launch day was the checklist; this is the calendar it hands you.

Sources#

1. Steamworks Documentation — Discounting: release and discount cooldowns, seasonal sale exemption, launch discount limits, timing discounts to content updates
2. Google Play Console Help — Monitor your app's technical quality with Android vitals: bad behavior thresholds, 1.09% crash rate and 0.47% ANR rate, 8% per device model
3. Google Play Console Help — Release app updates with staged rollouts: staged rollouts for updates and halting them
4. Steam Support — Steam Refunds: the 14-day, two-hour refund window