How many playtesters do you need?
How many playtesters an indie game needs depends on the question you are asking. Here is how to size a round, and how playtesting differs from QA.
For most indie playtests, five to eight testers per round is enough, because qualitative problems repeat fast: by the fourth or fifth person, you are usually hearing the same confusions again. You need larger numbers only when you are measuring something rather than discovering it, such as difficulty balance, drop-off rates, or comparing two versions. The real answer is that round size follows the question, and running four rounds of six will teach you more than one round of twenty-four.
The short version, by question type
| What you are asking | Testers per round | Why |
|---|---|---|
| Is the onboarding clear? | 5 to 8 | Clarity problems repeat almost immediately |
| Can players find and use feature X? | 5 to 8 | Discoverability is binary and shows up fast |
| Does the pitch match the game? | 8 to 12 | You need variety in how people describe it back |
| Is the difficulty curve right? | 15 to 30 | Skill varies enormously, so you need a spread |
| Where do players stop playing? | 20 or more | Drop-off is a rate, and rates need volume |
| Is version A better than version B? | 20 or more per version | Comparison needs enough signal to beat noise |
| Is the build stable across machines? | As many as you can get | This is QA, and coverage is the whole point |
Why small rounds beat big ones
The famous starting point here is Nielsen Norman Group's usability research, which argues that a handful of users surfaces the large majority of usability problems, and that you get more value from several small tests than one big one. That work is about software interfaces rather than games, and games add skill, taste, and long sessions on top, so do not treat it as a law. The underlying logic still holds: for finding problems, testers overlap heavily, and the fifth person mostly re-reports what the second one already told you.
There are three practical reasons small rounds win for indie teams.
You act between rounds. If you send the same build to twenty-four people, testers nine through twenty-four are all confirming a problem you identified at tester three. Their fifteen minutes bought you nothing. If you run six, fix, run six more, the second group gets to find the next layer of problems.
Testers are a limited resource. Every person who plays your onboarding is spent for onboarding questions forever, because next time they will already know where to go. Burning twenty-four fresh players on one build is expensive in a way that does not show up on any invoice.
You read six sessions properly and skim twenty-four. Be honest about the amount of open text you will actually sit with. Six thorough reads beat twenty-four skims.
When you genuinely need more people
Small rounds are for discovery. The moment you switch from "what is wrong?" to "how much and for whom?", you need volume.
- Balance and difficulty. Player skill spreads out hugely. Eight testers can easily be eight above-average players from your Discord, which will tell you the game is too easy while a wider group drowns.
- Drop-off and completion rates. A rate calculated over six sessions moves seventeen points every time one person quits. It is not a measurement, it is noise.
- A/B comparisons. Two versions with tiny groups will always look different, and the difference will usually be who happened to be in which group.
- Anything you plan to say out loud. If a number is going in a pitch deck or a devlog, it needs to be defensible.
If you cannot get those numbers, that is fine, and it is where most indies live. The move is to stay honest about it. Say "six of eight testers got stuck at the same door" instead of "75 percent of players get stuck," because the first is a true observation and the second implies a precision you do not have.
Playtesting is not QA testing
These get mixed up constantly, and mixing them wastes both. They ask different questions, need different people, and produce different lists.
| Playtesting | QA testing | |
|---|---|---|
| The question | Does this work as an experience? | Does this work as software? |
| Who is right | The player, always | The spec, always |
| Ideal tester | Fresh, representative of your audience | Systematic, willing to repeat the same input fifty times |
| Output | Design findings and priorities | Reproducible bug reports |
| A finding looks like | "I did not know why I lost" | "Loading a save from level 2 with the shield equipped drops the shield" |
| Repeat testers | Bad, they lose fresh eyes | Good, they build coverage |
| When | Continuously from prototype onward | Heaviest before release |
You cannot debate a QA finding. A crash is a crash. You must interpret a playtest finding, because the player is describing a symptom and you are diagnosing the cause.
The practical consequence: keep two lists. When a playtest turns up "I fell through the floor near the bridge," that goes to the bug list and does not consume design discussion. When it turns up "I did not realise the bridge was crossable," that is a design finding and it needs a decision, not a ticket. Teams that run one combined list end up with design questions buried under crash reports, and the design questions are the ones that decide whether the game is good.
A round schedule that works for a small team
- Prototype: three to five testers, one question, ugly build, unlisted link. Repeat weekly if you can.
- Vertical slice: eight to twelve testers, wider question set, screen recordings on, at each milestone.
- Pre-demo or pre-festival: fifteen to thirty fresh testers who have never touched an earlier build, including drop-off measurement.
- Pre-launch: as wide as you can reach, plus a separate QA pass on machines that are not yours.
Notice how the fresh-tester requirement gets stricter as you go. By the pre-launch round, your regulars are unusable for first-impression questions, and that is worth planning for early.
How to make each tester count for more
If you cannot increase the number of testers, increase what you learn from each one.
- Capture behaviour, not just opinions. Where they stopped, how long the tutorial took, what they never opened. This is data you get from every session without asking anything.
- Ask in the moment. A question that fires the third time someone dies to the same enemy is worth several post-session answers, because the frustration has not been rationalised away yet.
- Record the session. Watching two sessions often replaces a whole round of guessing.
- Ask better questions. Most of the value gap between a weak playtest and a strong one is question design, not sample size. There is a full bank in playtest survey questions that get real answers.
- Keep the wording identical between rounds so you can compare round three to round one instead of starting over.
Where the sample size stops mattering
At some point, more testers stop being the constraint, and your willingness to act becomes the constraint. I have watched myself collect a third round of feedback on a problem I had already understood after the first, because collecting is comfortable and changing the design is not. If you can predict what the next five testers will say, you do not need them. You need to go fix it.
That is also the argument for making rounds cheap to run. When a playtest takes twenty minutes to set up and costs nothing, you run one after every meaningful change, and the sample size question mostly answers itself over time.
This is what I built PlayProbe for. You share one link, testers play in the browser with no account and no download, and pre, post, and mid-game answers land aggregated in one dashboard. The free plan gives you one game, three tests, and twenty sessions per test, which comfortably covers three or four discovery rounds at the sizes above. Pro at $19 a month raises it to 200 sessions per test when you get to the stage where you are measuring rather than discovering. You can see what PlayProbe does here, and the guides on running your first playtest and finding playtesters cover the rest of the loop.
Start with five. Fix what they find. Then get five more.