Build and Release Management

Summary

Build and release management is the set of practices that turns a game from “playable” into “shippable”. It covers release candidates, hardening, submission timing, checklist discipline, platform review, and the handoff between development work and commercial launch.

Keith’s production framing is that hardening and release preparation must be planned, not improvised. Steam’s official docs then show what that planning looks like in platform terms: page review, build review, release-date handling, and final release actions. Console platforms add certification requirements on top of that (Keith, Agile Game Development, see source-agile-game-development; Steamworks Documentation, see source-steamworks-store-and-release; Microsoft, Xbox Requirements, see source-xbox-accessibility-and-certification).

Key ideas

Hardening is a real phase, not a mood

There is a point in production where adding features becomes less valuable than stabilising what already exists. That is the hardening transition. The team shifts focus toward:

• severe bug reduction
• performance stability
• onboarding clarity
• regressions
• store and submission readiness

If hardening has no explicit start, it usually happens too late.

Release candidates need clear rules

A release candidate is a build the team could plausibly ship if no critical issue is found. Without a shared definition, every build becomes “almost ready”, which destroys schedule visibility.

Useful release-candidate rules:

• no known crashers or data-loss defects
• no blocker progression bugs
• no broken store integrations or missing legal text
• no unreviewed late code merges

Submission buffers are part of the schedule

Steam asks partners to plan buffer time for both store-page review and build review. That means “launch day” is not just the day the team finishes development; it is the day by which reviewable assets, build, pricing, and timing decisions are already in place (Steamworks Documentation, see source-steamworks-store-and-release).

Console certification is stricter than standard PC release

Xbox’s documentation frames certification as a maintained set of requirements and tests, not a casual best-effort check. For teams used to PC release flow, this matters: platform integration, system behaviour, accessibility, and compliance all become explicit release blockers (Microsoft, Xbox Accessibility Guidelines and Xbox Requirements, see source-xbox-accessibility-and-certification).

Release management depends on source-control discipline

Release candidates are harder to trust if the team cannot identify what changed, reproduce builds, or isolate regressions. That is why release planning is tightly linked to source-control and, for larger teams, to branch strategy or CI/CD automation.

In practice

For a small team, a practical release-management checklist looks like this:

1. Freeze new features and define the hardening window.
2. Create a release candidate and log only shipping-risk defects against it.
3. Prepare store assets, pricing, and written copy in parallel with final bug fixing.
4. Submit store page and build with buffer time rather than on the last possible day.
5. Decide in advance which issues are blockers, which are shippable, and who can make the final call.
6. Prepare a launch-day checklist and a post-launch hotfix plan before release day arrives.

Evidence

Keith distinguishes feature-building from later hardening and argues that release quality depends on deliberate planning, not desperate overtime (Keith, Agile Game Development, see source-agile-game-development).

Steam’s official documentation describes release as a multi-step process involving review, release-date management, pricing, and final release actions rather than a single upload moment (Steamworks Documentation, see source-steamworks-store-and-release).

Microsoft’s Xbox documentation presents certification as a structured requirement set intended to ensure platform quality, reliability, and consistency (Microsoft, Xbox Requirements, see source-xbox-accessibility-and-certification).

Implications

• If a team cannot say what “ship-ready” means, it is not managing release yet.
• Submission calendars belong in production planning, not in marketing-only planning.
• Accessibility, platform behaviour, and QA are release-management concerns because they can all block or damage launch.

Open questions

• How much release-management overhead is appropriate for very small student teams?
• Which release-candidate rules should differ between premium single-player games and online games with server risk?
• When does a simple checklist stop being enough and require automated build verification?

Related

overview-full-game-development-pipeline | minimum-viable-game | qa-and-bug-triage | store-page-and-pricing-strategy | accessibility-and-localisation | source-control | post-launch-and-live-ops