Game Launch Day Checklist: 30 Things Not to Forget (2026)
Thirty checks for the day your indie game goes live: store flips and regional prices, the waitlist email, creator keys, crash triage, and a hard stop.
Launch day is not a holiday. It is an operations day with an audience watching: the build is finished, the store pages exist, and what remains is a sequence of small verifications and announcements where the only real failure mode is forgetting one of them. This checklist is the day itself, thirty items from the night before to the moment you close the laptop.
It assumes the setup work is already done. Developer accounts, listing assets, submission workflows: that territory belongs to the mobile publishing strategy guide and the Steam Direct walkthrough. If a step below sounds unfamiliar, it comes from one of those, not from today.
The day at a glance
| When | What happens |
|---|---|
| Night before | Freeze the build, stage every message, hand out creator keys |
| Launch morning | Make each store live, verify as a player would, announce |
| First hours | Watch crashes and reviews, triage, keep the issues list honest |
| End of day | Snapshot the numbers, write the log, stop working |
The night before
1. Freeze the build. The binary that passed review is the one that ships. "One more small fix" at eleven at night is how a re-submission eats your launch date, because every store puts a changed build back into its review queue. Fixes found tonight join tomorrow's hotfix, not today's release.
2. Install your own game the way a player will. A clean device, the store listing, the actual download: not your development machine, not a debug build. You are checking that the artifact strangers receive today is the one you tested.
3. Proof the store listing as a stranger. Price in the regions that matter to you, the first screenshot, the first line of the description, the release date field. This is the last cheap pass; the listing checklist lives in the App Store optimization guide.
4. Put the press kit somewhere public. A single page with GIFs, screenshots, a fact sheet of price, platforms and date, and your contact. Anyone who decides to write about you today should be able to serve themselves without asking.
5. Send creator keys tonight. Steam key batches to the press and creators on your list, press downloads on itch.io. Requests sent on launch morning get buried under everyone else's launch morning.
6. Stage every message you will send. The waitlist email, the Steam announcement, the Discord event, the social posts with your trailer link: write them all tonight, so tomorrow contains sending, not composing.
7. Write the day's runbook. One page: what happens at which hour, who you contact when something breaks, and the one condition under which you would pause the rollout. Decisions made in advance survive a stressful morning; decisions improvised during one do not.
Launch morning
8. Confirm the release state in each store. Apple's release-this-version-manually toggle, Google Play's staged rollout percentage, Steam's release button. You configured these weeks ago; this morning you verify them, because settings that were never re-checked are where surprise launches and missed launches come from.
9. Once it flips, buy or install it yourself. The page resolving is not the same as the build booting. Click the real install button in your main region and get past the title screen before you tell anyone anything.
10. Check the listing on a phone, on mobile data. Most of your first-day traffic meets the page on a small screen, including traffic for a desktop-only game.
11. Walk the full path a stranger would. Your site's store buttons, the store page's community and support links, the link in your social bios. Dead links on launch day are the cheapest thing on this list to prevent and the most embarrassing to miss.
12. On Steam, verify the launch discount and post the announcement. If you set a discount, confirm it applied: Valve suggests 10 to 15 percent for a launch discount, with a hard cap of 40, and it is the only discount a game can run within 30 days of release. Then publish the release announcement so followers see it in their activity feed instead of finding it by accident.
13. On Google Play, widen the rollout slowly. Start the staged rollout at a small percentage and watch Android Vitals before you open it up. And remember which kind of account you are on: reviews can take up to seven days, and personal developer accounts created after November 13, 2023 had to clear a closed test with 12 testers for 14 days before production was even possible, a gate that has caught many first-time publishers (why launches get stuck).
14. On the App Store, announce after it is live, not at a promised hour. Apple states that on average 90 percent of submissions are reviewed in less than 24 hours, but your game only needs to be in the slow tail once. "Out now at 3 PM" is a promise about a queue you do not control; "out now" with a link is not.
The announcement hour
15. Send the waitlist email first. The one audience you own exists for exactly this morning; the community you built before launch is the difference between a quiet release and a day with replies in it.
16. Post the Steam announcement and event. Followers get events in their feed; a release without an event is a release Valve's surfaces have to discover on their own.
17. Open the Discord day-one threads. A pinned "out now" post with the store links, and a known-issues thread you personally keep current. The second thread is about to become your unofficial support desk.
18. Send the social posts with the trailer. Written last night, sent now, best one pinned on each profile.
19. Post the launch thread where you have earned the room. Subreddits and forums with rules you have read and a history of you contributing. If you have not earned a community, skip it: a self-promo post that gets deleted helps no one and gets remembered.
20. Answer the first wave personally. Early buyers, first comments, the friend who shared it. You will never be this reachable again, and day-one attention compounds.
The first hours
21. Watch the crash and ANR reports. Android Vitals and the Xcode Organizer give you the numbers on mobile. Steam has no crash dashboard, which means your known-issues thread is the instrument: staff it.
22. Read the early reviews and respond where the store allows it. App Store and Google Play both let developers answer reviews, and a calm reply to a two-star report of a real bug reads better than fifty five-star reviews. On Steam you cannot answer a review directly; patch notes and update posts are the reply.
23. Triage by blast radius. Crashes affecting many players first, blockers affecting some second, typos last. One fix shipped well today beats five shipped in a panic.
24. Resubmit with the review clock in mind. A mobile fix usually clears review within a day, but it is not instant; on itch.io the same fix is live in minutes. Same bug, different platforms, different patience required from players, which is worth remembering when you pick where the day's energy goes.
25. Keep the known-issues pin honest. Update it as reports land and get confirmed. A visible, current list of what is broken turns anger into patience faster than any apology.
26. Say thank you publicly, with names. The creators who covered the game, the first reviewers, the Discord regulars answering other people's questions in your absence. One post, written by hand, no template.
End of day
27. Snapshot the numbers. Units, gross revenue, refunds, review average and count, wishlists remaining, top traffic sources, all written down at a fixed hour. Tomorrow starts a comparison, and the day-one baseline does not survive in your head.
28. Write the day-one log. What broke, which items on this list you skipped, what you would add for the next game. Ten ugly lines tonight are worth a week of reconstruction next month.
29. Queue tomorrow's output. Fix notes for the players who hit bugs, the thank-you post, the next devlog entry. Day two should begin with publishing, not with deciding what to publish.
30. Set a cutoff and honor it. Pick the hour after which nothing ships today, then close the laptop. Tired developers push bad fixes at midnight; the game, the bug list and the players will all still be there tomorrow.
The part that repeats
Items 1, 9 and 24 of this list repeat for every update you ship after launch, at a smaller scale: freeze, verify as a player, resubmit and wait for review. That loop is the unglamorous half of running a live game, and it is the part we are building Egmatic to shrink: the editor's publish layer exists so that "get the fixed build onto every store" stops being an afternoon of console-hopping. It is pre-alpha, and the waitlist on the landing page is how you can watch that turn from a claim into a button.