A Steam demo is one of the best tools you have for building wishlists before launch. It’s also a small release in its own right, with its own store page, its own build, and its own trip through Valve’s review queue. Devs are often surprised by that. They think a demo is a setting they flip on the main game. It isn’t. Here’s how it actually works, and how to get yours live without losing a week to avoidable mistakes.

A demo is a separate app, not a toggle

On Steam, your demo is its own application with its own App ID, linked to your main game. Players see it as a “Download Demo” button on your game’s store page, but behind the scenes it’s a distinct product: its own build, its own depot, its own store page fields.

Because it’s a separate app, the demo goes through Valve’s review like any other release, so budget time for it. But you also get to control it independently. Update it, take it down, or leave it up after launch, all without touching the full game.

To create it, go to your base game’s App Landing Page in Steamworks, click “All associated packages, DLC, demos and tools,” then click “Add Demo” at the top of that page. If you don’t see the button, your base game likely needs to clear its own initial setup first.

What you need before you start

Get these ready before you touch the submission flow. Scrambling for them mid-process is what stalls demos.

  1. A Steamworks account in good standing, with your base game past its Steam Direct fee. That fee is $100 per app, recoupable once the app earns $1,000 in adjusted gross revenue. The demo doesn’t need its own fee. It rides on the base game once you create it as an associated app.
  2. A working demo build. Cut down from your main game, scoped to a clear slice. It uploads to its own depot, not your game’s depot. Anything shared between the demo and the full game, art or audio you’re not cutting, can live in a shared depot that both apps mount, so you aren’t duplicating files. If you’re scripting your release pipeline, depot builds can be automated with SteamCMD rather than uploaded by hand each time.
  3. Store page assets for the demo. You can give the demo a full separate store page or just supply a few assets that show up on your base game’s page. A separate page needs its own description, at least five screenshots specific to the demo, and an accurate content survey, even if your full game already has one filled out.
  4. A clear cutoff. Decide exactly where the demo ends and what it includes. Players shouldn’t be able to reach full-game content through it.
  5. Your release timing. Know whether you’re launching the demo on its own or tying it to an event like Steam Next Fest, because that changes your schedule.

The steps to get it live

Once the demo app exists, the path looks like this:

  1. Build and upload the demo to its depot. Treat it like a real build. Test it on a clean machine, because “works on my dev box” is where demo launches go wrong.
  2. Set the demo to free. Demos aren’t purchased. Confirm the pricing and package settings reflect that.
  3. Fill out the demo’s store page and content survey. Description, images, and the basics, plus content descriptors for the demo itself. Keep it honest about what the slice contains.
  4. Set the build live on the right branch. Make sure the build players will download is the one you actually tested, on the default branch.
  5. Submit for review. Valve reviews both the build and the store page before the demo can go public. This is a real review, not a formality.
  6. Release. Once approved, you control when the demo goes live and when the “Download Demo” button appears on your game’s page.

Build in time for review

Plan for Valve’s review to take a few business days at minimum, longer around busy periods or if you fail the first pass. Build and test the demo. Submit for review with several business days of buffer. Release once approved. Don’t anchor a public announcement to a date you can’t control.

The pattern that hurts devs most: they announce a demo for a specific day, the review runs long, and now they’re stuck either delaying publicly or shipping a build they didn’t finish testing. Submit early. Give yourself slack.

If you’re targeting Steam Next Fest, the timing gets stricter. Next Fest runs three times a year (February, June, October) and is open only to unreleased games. Your title can’t have joined a previous Next Fest, can’t be a prologue or short-form preview of a game already released on Steam, and can’t launch before the edition ends.

Registration happens on your base game, not the demo, and typically closes about four weeks before the event. From there, Valve’s own workback timeline gives you two real deadlines. Want your demo live for Press Preview, about eleven days before launch? Submit for build review at least four weeks out. Fine skipping Press Preview? You have until two weeks out. Either way, release the demo at least 30 minutes before Next Fest starts, so you have time to catch problems before the crowd shows up. Miss a deadline here and you’re not just delayed, you’re usually waiting for the next edition.

Common mistakes that hold demos up

  • Treating the demo build as throwaway. It represents your game to a first-time player. A crash in the first five minutes costs you the wishlist.
  • Leaving full-game content reachable. Cut it cleanly. Reviewers and players will find the seams.
  • Forgetting the demo is reviewed separately. A green light on your main game’s page doesn’t mean the demo is approved.
  • Announcing before approval. Get through review first, then announce. Not the other way around.
  • Ignoring what carries over. Wishlists carry automatically. Save progress can too, if you route the demo’s save data through the same Steam Cloud storage as the full game, but that only works once the full game is actually released. Disable achievements in the demo and grant them after purchase instead of trying to carry them over; it gets messy otherwise.
  • Missing the wishlist notification window. The first time your demo goes live, you get one shot to trigger a notification email to everyone who’s already wishlisted the base game, and only within the first two weeks. Use it on purpose, not by accident on day one.

When to release it

A demo can go up well before your game launches, which is the point: it drives wishlists during the window when wishlists matter most. Valve’s own general guidance leans toward launching at release, but plenty of successful demos go out earlier, especially if players need hands-on time to understand a genre or mechanic before they’ll wishlist. If you want a rule of thumb, six to twelve weeks before launch is commonly cited among devs as the sweet spot for building momentum without the demo going stale in players’ libraries.

You can also keep a demo live after release, though many studios pull it at launch. There’s no single right answer here. Decide based on your game and your goals, and remember that because the demo is a separate app, changing your mind later is straightforward.

The short version

A Steam demo isn’t a toggle. It’s a release: its own App ID, its own build, its own store page, its own review. Before you submit:

  • Base game past its Steam Direct fee, demo app created and linked
  • Demo build tested on a clean machine, scoped to a clear cutoff
  • Store assets and content survey filled out for the demo itself
  • Pricing set to free, build live on the right branch
  • Submitted for review with enough lead time to absorb delays
  • No public date announced until you’re through review

Get that right, and the demo does its job: people wishlist your game before it’s even out.

If you’re planning a Steam release and want a second set of eyes on your demo and submission timeline before you commit to a date, reach out. We do this for a living.