Demo, closed beta or playtest: what each one is and when to use it

A demo, a closed beta and a playtest are usually described as the same thing: letting people play your game before it is finished. They are not the same thing. Each answers a different question, needs a different build, and gives you a different kind of answer. Confusing them is how studios end up with a thousand wishlists and no idea whether the first hour works — or with a "beta" that nobody finished.

This guide puts the three side by side: what each one is, what it actually proves, what it costs, and when to reach for it.

The three, in one line each

A demo is a finished slice you publish so players can decide whether they want the game. A closed beta is a near-complete game you open to a limited group so you can test it at scale. A playtest is a short, focused session where you watch and ask in order to learn one specific thing about the game.

The difference is not how much of the game is in the build. It is what you are trying to find out, and who is doing the talking.

What each one actually proves

A demo proves demand. Players vote with their time and with the wishlist button, and you learn whether the premise, the art and the first hour pull people in. You do not learn why they left.

A closed beta proves readiness. Hundreds or thousands of players on a build that is almost final: server load, progression curves, exploits, crashes nobody reproduced in-house, how long the game actually takes. You do not learn whether the combat is fun.

A playtest proves design decisions. You choose the question — is the tutorial too long, is this boss fair, do players understand the crafting menu — and you put the build in front of people who will answer it. You do not learn whether the game will sell.

Three different questions, three different tools.

Demo: publish a slice and see who shows up

Use a demo when you need to know whether anyone wants this game, and when you can afford to let strangers judge it.

A demo is public and unattended. There is no one explaining the controls, no follow-up interview, no second chance. It has to work on its own, and it has to end at a point that leaves the player wanting more rather than satisfied.

Good moments to publish one: - Your first hour is finished and polished, and the premise is strong enough to explain itself in a screenshot. - You are building a wishlist list before launch and need traffic that converts. - You want to see how players behave when nobody is watching.

What to watch: how many people finish the demo, how long they play, and how many add the game to their library. What it costs: the polish work, the store page, and the risk of a first impression you cannot take back.

Closed beta: open the doors to a limited group

Use a closed beta when the game is nearly done and you need to know whether it holds up with more people than your team can put in front of it.

A closed beta is about volume and endurance, not opinions. It runs on a build that is close to final, with a defined start and end, and with a way to report what breaks. The value is in what only large numbers reveal: the progression wall at hour six, the item that trivialises the mid game, the crash that needs 400 players to appear.

Good moments to run one: - Content is complete and you are in the polish and balancing phase. - You have online systems, live services or a difficulty curve you cannot test alone. - You need a stress test before release, not a design debate.

What to watch: crash and bug reports, completion rates, where players stop, and how long a full run takes. What it costs: coordination, infrastructure, and a real risk of burning out the goodwill of the people who showed up early — so keep the group bounded and the expectations explicit.

Playtest: ask one question and get an answer

Use a playtest whenever there is something in the game you cannot resolve by looking at it yourself.

A playtest is small, short and directed. You pick one objective, prepare a build that covers only the part of the game connected to it, choose testers who actually play your genre and your platform, and ask a small set of questions designed to produce a decision. Then you read the answers and change something.

Good moments to run one: - A prototype: does the core loop make sense at all? - A vertical slice: is the pacing right, and where does attention drop? - A balancing pass: which weapon, enemy or boss feels off? - A localisation or clarity check: which screen confuses people?

What to watch: the answers to the question you asked, plus the behaviour around it. What it costs: very little — a build, a handful of testers, a form, and a few days. That low cost is the whole point: a playtest is cheap enough to run often, and a demo or a beta is not.

Which one do you need right now?

Three quick checks:

Nobody knows whether your game is worth playing → demo. The game is almost finished and you need to know if it survives real players at scale → closed beta. Something in the game is not working and you do not know what → playtest.

If two of those apply, do them in that order of urgency: fix the design problem first, then show the game to the world. A demo of a broken first hour only tells you, loudly, that the first hour is broken.

The sequence most indie studios can follow

1. Playtest a prototype, with five to ten people, to find out whether the core loop is worth building. 2. Playtest a vertical slice to check pacing, clarity and difficulty before you commit to full production. 3. Publish a demo when the first hour is finished, to build an audience. 4. Run a closed beta when the game is complete, to find what only volume reveals. 5. Keep playtesting small questions in between — every cycle costs days, not months.

The demo and the beta are events. The playtest is a habit. Studios that only run the events learn too late.

Mistakes that cost months

Running a beta when you needed a playtest. You collect a thousand bug reports and still do not know whether the game is fun. The beta was never going to answer that question.

Publishing a demo before the first hour works. The demo becomes your first impression forever, and the people who bounce rarely come back to check.

Treating a playtest as a marketing moment. If the objective is publicity, the answers you get are publicity-shaped. Keep early tests small and honest.

Never closing the loop. A playtest whose results nobody reads, or whose changes are never told to the testers, teaches the team nothing and costs you the testers' next session.

How Playtest Hub helps

Playtest Hub is built for the third of the three, and for running it often.

A studio creates a playtest for a game, sets the testing period and the maximum number of testers, and writes a feedback form using six question types — short text, long text, rating from 1 to 5, single choice, multiple choice and yes / no. Testers apply, and the studio chooses who joins; the build link is shown only to the testers the studio approved. During the testing period, players submit their answers and can report bugs, and studios can reward participation with Credits. When the playtest ends, the Results page summarises that playtest on its own: participants, feedback submitted, response rate, and a breakdown per question — average and median with the distribution for ratings, counts and percentages for choices, and every written answer for text questions.

None of that replaces a demo or a closed beta. It is the tool for the question you can only answer by watching someone else play.

Pick the tool that matches the question you actually have. Then run it, read what comes back, and change the game before you show it to everyone.