Eleven days before launch, someone on your three-person team adds a new weapon. It is a good weapon. It also touches the damage formula, two UI icons, a localization string nobody translated, and an achievement that now fires on the wrong event. You find out on launch morning, from a player, in a one-star review.
Nothing about that story requires incompetence. It requires only the absence of a date on which the game stopped changing. Most small teams plan production in detail and then treat the last month as "polish and bug fixing" — one undifferentiated block with no entry or exit criteria. That block is where launches get decided.
Here is a runbook for the final four weeks: three separate freezes, a bug bar that settles arguments before they start, and a release-candidate checklist you can sign off.
Three freezes, not one
"Freeze" fails when it means everything at once. Split it into three gates that close in sequence, each with its own allowed changes.
Feature lock (T-28). No new systems, verbs or UI screens. Existing features can still be tuned, rebalanced and fixed. The honest test: if a change needs a new design document section, it is a feature, and it is out. The point is to stop spawning untested surface area while QA time shrinks.
Content lock (T-14). No new levels, items, enemies, quests, dialogue lines or audio assets. Existing content can be adjusted — a room's layout, a numbers pass, a re-record of a mumbled line. This is the lock that makes localization and a full playthrough test possible, because the string table and the level list stop moving.
Code freeze (T-5). Only fixes that clear the bug bar below, each reviewed by a second person and followed by a fresh playthrough of the affected area. By now every change is a risk trade, not an improvement.
| Window | What closes | Still allowed | Exit criteria |
|---|---|---|---|
| T-28 → T-15 | New features, systems, screens | Tuning, balance, bug fixes, content finishing | Every feature in the build is playable start to finish; no TODO placeholder UI |
| T-14 → T-6 | New content, new strings, new assets | Layout edits, numbers passes, re-records, fixes | Full playthrough logged by two people; 100% of strings in the translation export |
| T-5 → T-1 | Everything except bar-clearing fixes | A-bugs only, each paired with a verification pass | Release candidate signed off (checklist below) |
| T-0 | — | Hotfix branch only | Launch rota staffed |
Put those dates in your milestone timeline the day you pick a release date, not the week you reach them. The Milestones and Task Board modules in GameDesignerX are the natural home for them: each freeze is a milestone with its exit criteria in the description, so "are we feature locked?" has a checkable answer instead of a vibe.
Write the bug bar before you need it
A bug bar is a one-page definition of what you will and will not fix, written while nobody is panicking. Without one, every bug becomes a 1 a.m. negotiation that the loudest person wins.
Three severities are enough for a small team:
- A — blocks the game. Crash, hang, save corruption, progression stopper, store or platform violation, a feature that does not work at all. These fix before ship. No exceptions, including during code freeze.
- B — damages the experience. Wrong numbers, broken audio on a common action, a soft-lock that an alternate route escapes, text clipped in a supported language, an achievement that fires late. These fix before ship if they are cheap and isolated; otherwise they go to the day-one patch.
- C — cosmetic or rare. A floating prop, a typo in a codex entry, a visual seam visible only from outside the playable space. These go to the backlog and ship as known issues.
Two rules make the bar work. Severity is about player impact, not how much the bug annoys you — a shader seam you have stared at for a month is still a C. And one named person assigns severity, with one written appeal allowed if there is new information.
A sensible target before you call a build a release candidate: zero open A-bugs, and a B list short enough to read aloud in under two minutes. If the A list is still growing at T-7, you do not have a bug problem — you have a date problem.
Release candidate criteria
A release candidate is not "the latest build." It is a numbered build that someone has verified against a written list, short enough to run in a day. A usable baseline:
- Clean install to credits, on the lowest spec you advertise, played by someone who did not write the last fix
- Eight hours of combined play across the team with no new crashes
- Saves from the previous build load, or you ship a documented save wipe and say so publicly
- Cold start with a controller only — no keyboard touched, including menus and name entry
- Every language you ship checked for overflow on the five longest screens
- Audio sliders, resolution, fullscreen and key rebinding all persist across a restart
- Achievements fire on a fresh account, not just your dev account with everything unlocked
- The uploaded build runs from the store client on a machine that has never had your project folder on it
- Credits, legal notices and third-party licences present and correct
- A rollback plan: the previous build is still uploadable, and you know which command does it
That second-to-last item catches a classic: the game that only runs because your machine has a dependency installed. Test from a clean user account with a review key, exactly as a buyer would. The Steamworks Prep and Build Tracking modules are useful here mostly as memory — the RC number, who verified which line, and when.
Decide the day-one patch now
Your B list will not be empty. Decide in advance how it ships:
- Freeze the RC and keep fixing on a separate branch; those fixes become the day-one or day-three patch.
- Publish the known issues — store page, pinned post or in-game notice. A disclosed bug is forgiven far more readily than one a player discovers and reports into silence.
- Hold the patch until you have 48 hours of real crash reports. The bugs players hit are usually not the ones on your list, and patching in the first hour spends your only quiet window on guesses.
Staff launch week like a shift, not a vigil
Three people awake for 30 hours is worse than three people covering ten hours each. Write the rota before launch day, with names and hours, and name an owner for each of: crash reports, store discussions and reviews, support email and refunds, social and press replies. Agree one escalation rule — what wakes the person who can build a hotfix — and let everything else wait for the next shift.
When you slip
If the A list is not shrinking by T-7, you have three levers, and you must pull one deliberately instead of hoping.
- Cut content. Pull the chapter, biome or mode with the most open bugs. A smaller finished game beats a bigger broken one.
- Move the date. Expensive with marketing beats booked, survivable if you tell partners early. Two weeks bought at T-10 is worth more than two bought at T-2.
- Ship with known issues. Only ever with A-bugs closed, a published list, and a patch already in flight.
Pick one, record which and why in your decision log, and give the whole team the same sentence. The failure mode is not choosing — carrying all three options for another five days while the list grows.
The one-page version
Put the release date on the calendar. Count back 28, 14 and 5 days and name those gates. Write the bug bar this week, while it costs nothing. Define the RC checklist, run it on a real build, and sign it with a name and a date. Decide the patch policy before launch, not during it. Staff launch week in shifts.
None of this makes your game better. It makes the version players buy the same version you tested — on launch day, the only quality you control.