STEAM NEXT FEST DEMO FREEZE CHECKLIST
PlayablePlan | https://playableplan.com/game-development-project-management

Copy this checklist for your candidate build. Assign an owner and record evidence
for each applicable check. Mark non-applicable items explicitly. This is a planning
document, not an import file for PlayablePlan or a substitute for Steamworks review.
Verify current event requirements and dates in the official documentation:
https://partner.steamgames.com/doc/marketing/upcoming_events/nextfest

BLANK FREEZE RECORD

Game and event edition:
Candidate build/version:
Demo App ID and intended branch:
Freeze owner:
Current official review/submission deadline:
Player route and expected end state:
Target platforms and input devices:
Known accepted issues:
Last verified candidate / rollback point:

FOR EACH CHECK
Status: pending / passed / failed / not applicable
Owner:
Evidence (build, device, result and date):
Retest required after which changes:

RELEASE CHECKLIST
[ ] Confirm the current event requirements and official dates.
[ ] Confirm the intended demo App ID, depot, package and branch configuration.
[ ] Confirm review status for the required store page and build submissions.
[ ] Install the exact candidate package on the supported target configuration.
[ ] Launch from a clean state and start the demo without editor dependencies.
[ ] Verify keyboard/controller detection and the required control mappings.
[ ] Complete the promised gameplay route without crashes or progression blockers.
[ ] Check pause, settings and resume, including controller focus.
[ ] Check save/load if the demo supports it; verify existing progress is preserved.
[ ] Reach the final demo state and verify the exit/restart path.
[ ] Check that the store description and media match the available demo content.
[ ] Confirm required art, audio and localization files are present in the package.
[ ] Record accepted non-blocking issues and assign the final go/no-go decision.
[ ] Record the final build ID, evidence and owner after the last approved change.

LATE-CHANGE DECISION
Player-facing problem:
Category: must fix / safe change / after the event
Reason the change is needed before release:
Owner and approval:
Affected route and exact retest:
New candidate build ID:
Retest result:

Must fix: crashes, broken progression, corrupted saves or unusable required controls.
Safe change: a narrow correction with a clearly bounded and completed retest.
After the event: desirable polish, extra features and refactors not needed for the demo.

FILLED EXAMPLE (HYPOTHETICAL)

Game: Forest Courier
Candidate: First delivery demo, version 0.4; insert your own Steam build ID.
Freeze owner: Alex
Player route: Start a delivery, cross the forest, deliver the parcel, restart.
Issue: Controller focus disappears after returning from Settings.
Category: Must fix, because the player cannot resume the required route.
Owner: Alex fixes the focus transition; Sam verifies the packaged candidate.
Retest: Clean launch with controller, open Settings, return, complete a delivery,
restart, then repeat using keyboard. Record the device and candidate build ID.
Deferred: Additional hit-spark effects, which do not block the promised demo.
Accepted issue: A cosmetic foliage pop at the route entrance, documented for later.
Go/no-go: Pending until the controller retest passes on the candidate package.

In PlayablePlan, use one milestone for the candidate build. Add the must-fix tasks,
assign their owners and make missing exports or checks visible as blockers.
Keep after-event work separate so it does not obscure the release decision.

Guide: https://playableplan.com/blog/how-to-freeze-your-steam-next-fest-demo-without-stalling-development