Free Demo vs Paid Prologue: Which Should You Ship?

A demo is low-effort and attaches to your main page; a prologue is a separate free product with its own page, reviews, and algorithm presence — far more reach, far more work and risk. Ship a demo by default; consider a prologue only if you can afford to polish a standalone slice to review-safe quality. That's the short version — the sections below get into the how, the why, and the mistakes worth dodging.

Why prologues exploded in the first place

A free standalone 'Prologue' gets what demos historically didn't: its own store page, its own wishlists and reviews, presence in free-game charts, and a second set of tags feeding the discovery machine. For a while this was a genuine visibility exploit, and big indie launches rode it.

Valve has since given demos more of those powers — demos can have their own page presence and appear in more surfaces — which narrows the gap and weakens the case for the extra work.

The prologue's hidden bill

A prologue is a shipped product: it needs its own capsule, page, QA, patches, and it collects reviews that color your main game's reception. A buggy or thin prologue earns 'Mixed' publicly and permanently — marketing that actively damages you. The polish bar is the same as a paid release, with none of the revenue.

Budget honestly: most teams underestimate prologue cost by treating it as 'just cut down the game'. It's a second SKU, with everything that implies.

Decision rules that hold up

Choose a demo when you want feedback, festival eligibility, and conversion help with minimal overhead — that's most indies, most of the time. Choose a prologue when the game is large, the slice stands alone as genuinely satisfying, you have months of slack, and your wishlist engine needs a bigger flywheel than a demo provides.

And never both half-heartedly. One excellent free experience beats a mediocre demo plus a mediocre prologue, each quietly underselling the same game.

Look at your page like a stranger would

You know your game too well to see your own store page clearly. A stranger gives it a few seconds: capsule, title, first screenshot, opening line of the description. If those four things don't communicate the genre and the hook, the visit is over before your feature list ever gets read.

Borrow fresh eyes whenever you can. Watch a friend scroll the page cold and narrate what they think the game is. Where their guess diverges from reality is exactly where the page needs work.

Decisions need data, even small data

Steam gives you more numbers than most indies ever open: wishlist conversion, page traffic sources, click-through on capsules during festivals. You don't need a data science background — checking a handful of charts once a week tells you whether a change helped or just felt productive.

The same habit applies in-game. Knowing how many players actually reach level two, or how many sessions end in a crash, turns arguments about priorities into quick decisions. Instrument the few numbers that matter and let them referee.

The quiet work that protects all of this

Everything in this post gets undone by an unstable build. A great store page, a clever marketing beat, a perfect jam entry — none of it survives 'crashed twice, refunded'. Stability isn't a feature players praise, but it's the floor everything else stands on.

Give yourself visibility before you need it: crash reports with stack traces, a simple way for players to flag issues from inside the game, and a habit of fixing the top recurring error before adding anything new.

Putting it to work

Don't try to act on all of this at once. Pick the one change that costs you the least and pays the most this week, do it, and see what actually happens before reaching for the next.

Most of this rewards steadiness over intensity. A small improvement made every week, checked against how real players respond, outruns any single burst of effort — in this corner of game development and every other one.

Your store page is part of the game. Patch it like one.