The last eight weeks: a launch checklist

Eight weeks out: stop adding

• Feature freeze, properly. No new systems, no new content sets. Anything not in the build now ships in an update or not at all.
• Agree the bug bar. Which severities block launch and which do not, written down, so the decision is not made at 2am by whoever is most tired.
• Lock the string list. Localisation cannot start while text is still changing, and it needs weeks, not days.
• Confirm the certification window with each platform, including the queue, and put the submission date on the plan as immovable.
• Have the store page live already. If it is not, that is the most urgent item on this list, per your Steam store page.

Six weeks: the passes nobody scheduled

Each of these is a day or three, each finds real problems, and all of them are routinely discovered in the final week instead.

Five weeks: submission

1. Build a release candidate and treat it as final. Every subsequent change is a decision, not a habit.
2. Run the platform's own requirement list against it before submitting. Most failures are for known, listed items.
3. Submit early enough to fail once. Assume a rejection and a resubmission in your dates.
4. Prepare the ratings, if they are not done. Through IARC, digital store ratings are typically a questionnaire rather than a fee.
5. Lock the price and the regional pricing, and check the currency conversions look sane rather than automatic.
6. Set up the release build pipeline so producing a patch does not require the one person who knows how.

Four weeks: the marketing beat

• Send press and streamer keys now, not on launch day. Coverage needs lead time, and a key that arrives on the day arrives after the decision.
• Update the store page to launch quality. New capsule if the old one was placeholder, current screenshots, final description.
• Write the launch-day copy in advance, because you will not want to write it on the day.
• Check every link in every place you exist: page, socials, press kit, website.
• Confirm the launch time, in a specific time zone, and tell everyone who needs to be awake.

Two weeks: freeze harder

• Only crash and progression-blocking fixes. Every other change risks introducing something worse than it fixes.
• Re-test after every accepted fix, on every platform. This is where late regressions are born.
• Prepare support. Where do players report problems, and who reads it in week one?
• Write the known issues list, publicly if you can. Players are forgiving of acknowledged problems and unforgiving of silence.
• Back everything up, including the exact build that shipped and the exact source it came from. You will need to rebuild it from that state later.

Launch week

1. Nobody changes the build. Unless it is on fire.
2. Watch the first hours of reviews and forums for the two or three problems that recur. Those are your patch.
3. Respond to the recurring ones publicly, briefly, without arguing.
4. Watch the refund reasons if the platform gives them. It is the most honest feedback you will get all year.
5. Do not read every individual comment. Read patterns and let one person triage.
6. Sleep. The team has to be functional for the week that matters more than launch day, which is the one after it.

The week after

• Ship a patch for the recurring issues, quickly, and say what is in it.
• Tell players what is coming next, even briefly. Silence after launch reads as abandonment.
• Write the post-mortem while it is fresh, including the schedule numbers, so the next project estimates better.
• Check your actual revenue against list price and understand the gap, which is covered in what a game actually costs to make.
• Decide about content updates deliberately, based on how the game performed, rather than by default.

The last eight weeks are not for making the game better. They are for making sure the game you already made arrives intact.

The items most often missed

1. Certification queue time, budgeted as days rather than weeks.
2. The platform states: controller disconnect, storage full, save failure, network loss. All required, all absent from most screen lists, per from core loop to screen list.
3. Localisation testing, as opposed to localisation.
4. Minimum-spec testing on actual minimum hardware.
5. The library and store assets at their current required sizes.
6. Legal screens, age gates and data consent where they apply.
7. The credits. Everyone who worked on it, spelled correctly, including contractors.
8. A press kit that exists before anyone asks for one.