When to Turn Your Playtest into a Steam Demo

The question of when to release a game demo is really a question about three clocks you do not control: the Next Fest calendar, the build review queue, and the one email Steam lets you send to your wishlisters. The playtest side of the schedule is repeatable. A round of five testers, a friction log written the same day, a fix, another round next month. The demo side is a row of one-way doors, and the whole skill is arriving at each door after the build is ready and before the window closes.

The anxiety around this transition has a voice now. In the community reads we run every week, September's playtest threads kept circling the same jump, and one developer pinned it exactly: "I only get one chance to press the email wishlisters button." That sentence is the whole problem in miniature. A playtest is gated: you admit specific players, watch what breaks, and revoke access when the round ends. A demo is public: it sits on your store page, anyone can download it, and the people who enjoy it often wishlist the game while the tab is still open. This article is about the seam between the two states: what the playtest must prove before a demo should exist, how to count back from the fest, and when to press the one button. A disclosure before we start: this blog belongs to Egmatic, a no-code 2D editor in pre-alpha, and what that has to do with demo timing is near the end.

Quick answer#

The surrounding system is covered elsewhere and this piece will not repeat it: how to recruit playtesters fills the rounds, how to run a playtest makes each round produce signal instead of nods, and getting your first 100 Steam wishlists grows the list the one email lands on. What follows is only the timing.

The ladder from closed doors to public#

The transition is not one step but a ladder, and each rung answers a different question.

Day one: a link anyone can click. A web build on itch.io, shared wherever you already talk about the game. The point is not polish; it is having a public artifact while the game is still embarrassing. How to put that build up is its own job, covered in how to host a playable web demo.

Closed playtest rounds. Specific players, a frozen build, a script, and a friction log. This is the machine that makes everything later safe, and it is the subject of the session guide linked above. Rounds repeat until the build stops surprising you.

Steam Playtest. A gated test that lives on your store page itself: players click a request button, you admit them in batches, and access ends when you end it. It bridges the two worlds, because wishlisters get something to play before a public demo exists, and you keep the gate. One note to hold for later: a Playtest running during Next Fest splits your players between two builds, so close it before the fest opens.

Public demo, then Next Fest. The demo is a separate App ID attached to the base game, linked automatically from your store page and from the player's library back to the full game, and it surfaces in New and Trending and on tag and genre pages. Next Fest is the amplifier: a weeklong event, three times a year, that puts unreleased games with demos in front of an audience that came specifically to browse them.

Release. The paperwork belongs earlier in the calendar than most developers put it, and the Steam Direct walkthrough covers it end to end, including the $100 fee per product, recoupable after $1,000 in adjusted gross revenue.

Each rung answers a different question, and the rung below cannot answer the one above it. A playtest answers what is broken. A demo answers whether strangers want this. The fest answers how many strangers can find it in one week.

What the playtest must prove first#

The gate is the phrase our own wishlists piece uses, and it holds here: several small playtest rounds until the build survives strangers. Readiness is visible in the friction log, the same one the session guide has you keep: one line per incident, timestamp, what the tester was trying to do, what they did, what they said.

• Stuck points have moved from controls to content. Round-one testers ask what the jump button is; round-four testers argue about which door to take. The first problem is yours to fix; the second is what a game is.
• Round three hits the same walls as round two. New testers surfacing old, known frictions is convergence. New testers surfacing new frictions every round means the fix loop is not keeping up with the discovery loop.
• A stranger finishes the slice with you out of the room. The silence test from the session guide, applied to the demo-to-be. If the build still needs a facilitator, it is not a demo yet.
• The frozen build is crash-free across a whole round. A demo that crashes in minute three burns the one resource no fix can restore, which is the first impression of a stranger with no obligation to you.

The demo itself should be a slice built for strangers, not the vertical slice you would show your community. Strangers arrive without context, without goodwill, and without you, so the slice has to explain itself and stop cleanly. A demo of the whole game asks a stranger to commit an evening; a slice asks for ten minutes and leaves them wanting the rest.

Count back from the fest#

The fest calendar is fixed and documented by Valve: Next Fest runs three times a year, in February, June, and October, and a title may participate in exactly one edition, ever. Registration happens on the base game's app landing page, and the demo must be submitted for build review no later than three weeks before the fest starts, five weeks if you want it live for the press preview. The store page that all of this hangs on needs seven business days of review on its own.

Worked backward, the calendar looks like this:

Two more calendar facts belong in the plan. First, add buffer for a failed first review; a rejected build re-enters the same queue, and a fest deadline does not move because your build bounced. Second, placement inside the fest is randomized for the first days and then personalized by player behavior, which means the fest rewards a polished demo rather than a clever launch minute. There is no advantage to submitting at the last second, and there is considerable risk in it.

The choosing rule falls out of all this: the edition that matters is the one closest to a launch-ready build, not the one with the nearest deadline. If the build is not fest-ready by the three-week mark of the nearest edition, the correct move is the next edition, not a rushed slice. A game gets one fest; the calendar offers three a year; patience is cheaper than a wasted slot.

The email you get to press once#

When your demo goes live, at any point and in any season, the wishlisters of the base game can be emailed about it exactly once. You have a 14-day window from demo launch to press that button, and it does not come back. Steam also enforces a two-week cooldown per App ID on notifications of this kind, so the demo email must be spaced away from any other wishlist trigger you are planning, a discount most of all.

Inside the window, the timing question is smaller but real. The window opens the moment the demo launches, and the crash reports arrive in the first hours. Pressing the button on minute one spends your one shot on a build that has met no one; pressing it on day fourteen spends it on whoever is still paying attention. The workable middle is to let the demo absorb its first strangers, ship the fixes their sessions surface, and press while the fest traffic, if you launched into a fest, is still live.

The developer quoted at the top was right about the stakes, and the answer to that fear is sequencing rather than hesitation. The email is not scary when the demo behind it has already survived the people who downloaded it in week one.

If the build is not ready#

Not being fest-ready is a schedule outcome, not a verdict. Three moves keep the momentum.

Put the public artifact somewhere cheaper. A web demo on itch.io gives strangers a link, gives you public feedback, and starts none of the Steam clocks. The hosting how-to linked above covers it; the timing point here is that it is the right intermediate step while the rounds continue.

Make the store page collect while you catch up. The page can go live and gather wishlists for as long as the game needs, and Valve's own guidance notes that a player who wishlists two years before release is about as likely to buy as one who wishlists two weeks out. Every week the page is up while the demo is not ready is a week the email list grows anyway.

Keep the rounds running. The ladder does not punish waiting. It punishes skipping, which is what happens when a deadline, rather than the friction log, decides that the build is done.

Common mistakes#

• Spending the fest on a build that exists. One Next Fest per title, ever. The edition worth attending is the one nearest a launch-ready build; attending the nearest one is how the slot gets wasted.
• Shipping the game as the demo. A demo is a slice built for strangers: self-explaining, clean stop, ten minutes. The whole game asks for an evening and a forgiveness no stranger owes you.
• Leaving Steam Playtest live during the fest. Valve's documentation says it directly: a Playtest running during the fest splits your players between two builds instead of concentrating them on the demo.
• Pressing the email in minute one. The window opens at launch and the crash reports land in hour one. Spend the button after the first fixes, not before the first stranger.
• Cutting the demo before the page is approved. The page is the longer queue and the thing the demo feeds. Approve the page, then cut the slice, not the reverse.
• Treating review as a button. Three weeks minimum, five for the press preview, and buffer for a failed first attempt. The queue does not know your deadline.

How Egmatic fits#

The work between "the playtest said fix this" and "the demo carries the fix" is publishing work: cutting the slice, freezing the build, shipping the update to the same link strangers already have. That road from scene to released build is the layer Egmatic is built around: a no-code 2D editor and engine whose ship layer carries the game to players instead of stopping at the canvas. The AI inside works as a craft amplifier under your direction: you decide what changes after a round, it executes, and every file stays yours, which matters most in exactly the weeks when the fix has to be in strangers' hands before the window closes.

We will state the stage plainly: Egmatic is pre-alpha, and we do not announce dates we cannot keep. The waitlist at egmatic.com is where the ship layer takes shape, and it is where you can tell us where your own loop stalls, whether that is cutting demo slices or getting updated builds to testers, because in pre-alpha the requests arriving now are the ones that steer the build.

Ship the demo, not just the decision.

A demo is a build strangers reach without you in the room. Egmatic is a no-code 2D editor with a publishing layer that carries demo slices and test builds to players without code or a backend. Reply on the waitlist with where your loop stalls: requests sent during pre-alpha are the ones that steer the build.

you@example.comGet Build News

No spam. Unsubscribe anytime.

Conclusion#

Three clocks, one gate. Playtest in rounds of five until the build survives strangers, because that is the gate every later step assumes. Approve the store page early; it is the longer queue and it collects wishlists the whole time. Count back from the fest: three weeks of review at minimum, five if the press preview matters, buffer for a failure. Spend the one fest on the edition nearest a launch-ready build. And when the demo goes live, press the one email inside its fourteen days, after the first strangers have downloaded it and their crashes have been fixed, and spaced away from any discount. The demo is not the announcement of a finished game; it is the first build that belongs to strangers, and it is ready exactly when it can survive them.

Sources#

1. Valve — Steam Next Fest (Steamworks Documentation): weeklong event, three times a year in February, June, and October; one Next Fest per title ever; public demo required; demo submitted for build review no later than three weeks before the fest starts, five weeks for the press preview; registration on the base game's app landing page; placement randomized for the first days, then personalized by player behavior; a Steam Playtest live during a fest splits players between builds
2. Valve — Demos (Steamworks Documentation): a demo is a separate App ID attached to the base game; automatic links from the demo page and the player's library back to the full game; demos surface in New and Trending and on tag and genre pages; one-time wishlist notification within 14 days of demo launch; two-week cooldown per App ID
3. Valve — Coming Soon (Steamworks Documentation): seven business days for store page review; two-week minimum Coming Soon page before release; the automatic release-day email to wishlisters; long-lead wishlists purchase at similar rates
4. Valve — Steam Direct (Steamworks Documentation): the $100 fee per product, recoupable after $1,000 in adjusted gross revenue
5. Community reads run by our team, September 2026: the weekly playtest-cycle threads behind our feedback digest, including the developer comment "I only get one chance to press the email wishlisters button" (23 September 2026)