Finding playtesters is not the hard part. Post in three Discord servers and you'll have a stack of volunteers by morning. The hard part is that most of them will play your game, hit a wall, quietly give up, and then tell you it was "really fun, good job."
That sentence has ruined more games than bad code ever will. It feels like validation and it contains zero information. The whole skill of playtesting is arranging things so people can't be polite at you — so the problems show up whether they want to mention them or not.
Here's how to find those people and get the truth out of them.
Why your friends and family are the worst testers
The people closest to you want you to be happy. That is lovely in a human being and useless in a playtester. They will forgive your tutorial because they know you spent a month on it. They will assume the confusing bit is their fault, not the game's.
They also can't see the game anymore. If they've watched it grow for six months, they already know the controls, the goal, and where the secret door is. They are the least equipped people on Earth to tell you whether a stranger can figure it out cold.
Use them for encouragement. Do not use them for feedback. Those are different jobs and only one of them requires honesty.
Where to actually find playtesters
You want strangers who owe you nothing. Start with communities built around the genre you're making — subreddits, Discord servers, forums where people already argue about the thing your game does. Someone who has strong opinions about deckbuilders will give you a far more useful hour than a generalist being nice.
Good places to look:
- Genre-specific Discords and subreddits. Ask permission first, then post a short, honest pitch. "Roguelike, 20 minutes, I want to watch you get stuck" beats a wall of marketing.
- Local or online game dev meetups. Other developers are brutal in the best way, because they know what to look for. The trade is that you have to test theirs too. Fair.
- Game jams and playtest-swap events. Structured environments where feedback is the whole point and nobody's feelings are fragile.
- Your own audience, once you have one. If you've done the work of getting your first 100 wishlists, some of those people will happily test — and they've already told you they care by wishlisting.
What you're avoiding is a room full of people who love you. You want a room full of people who love the genre and have never heard of you.
The one thing that beats every survey: watch in silence
If you take one thing from this, take this. The single most valuable playtest is watching someone play while you say nothing.
Get a screen share or sit behind them. Then shut up. When they hover over the wrong button, don't help. When they miss the exit that's right in front of them, don't point. When they say "wait, am I supposed to—" swallow the answer. Every time you rescue a tester, you delete the exact information you invited them to produce.
This is physically painful. You will want to explain. Explaining is the enemy. Your players at launch won't have you crouched next to them whispering "press E," so the test has to happen without you doing that either.
Watch their hands and their face, not their words. A tester who says "this is great" while frowning and mashing the same key is telling you the truth with their body and a lie with their mouth. Believe the body.
Keep a note open and log every moment of hesitation, every wrong turn, every sigh. You're not collecting opinions. You're collecting the places where reality diverged from what you assumed. That list is the whole gold mine.
How to ask questions that surface problems instead of politeness
Surveys and post-game chats have their place, but only if you ask properly. The default questions are traps.
"Did you like it?" invites a yes. "Was it fun?" invites a yes. "Any feedback?" invites "no, it was great." These questions are worded to make the tester comfortable, and comfort is the opposite of what you need.
Ask for specifics that assume a problem exists:
- "Where did you get confused?" — not if, where. The premise is that confusion happened, which gives them permission to name it.
- "What were you trying to do right before you got stuck?" — this surfaces the gap between your intended design and their mental model.
- "If you'd been playing at home, where would you have quit?" — the most honest question in the whole kit. Everyone has a quit point. Naming it is a gift.
- "What did you expect that button to do?" — tells you whether your feedback and signposting are working.
Never ask what they'd add. You'll drown in feature requests that solve nothing. Ask what frustrated them and fix the frustration your own way.
And when they do criticise something, resist the reflex to defend it. The second you explain why the confusing thing is actually fine, you've taught that tester to stop reporting problems. Just say "thank you," write it down, and move on. You can decide later whether they're right. Arguing in the moment only trains them to be polite.
Separating signal from one person's taste
Not all feedback is equal, and testers will confidently prescribe cures for problems they've correctly diagnosed. Your job is to trust the diagnosis and ignore the prescription.
If one person says the second level is boring, note it. If five people slow down, sigh, or quit at the second level, that's not opinion anymore, that's a structural fact about your game. Look for the moments that repeat across testers. Repetition is signal. A single strong reaction is a data point you keep in your back pocket.
When someone says "you should add a dash," translate it. They rarely want a dash. They want to stop feeling slow, or stuck, or unable to escape something. Fix that feeling. The dash was their guess at your job.
The uncomfortable part: the feedback that stings most is usually the feedback pointing at the thing you already suspected and hoped nobody would notice. If a note makes you defensive, sit with it. That reaction is often a compass.
Do it early, and do it often, with fresh people
Test before it's ready. Test the ugly prototype with programmer art and no sound. It's tempting to wait until the game is polished, but a polished game is expensive to change, and testers are far gentler on rough builds because they can see it's rough. Nobody roasts a sketch. They will absolutely roast a painting.
And you can only test a build fresh with someone once. The instant a person learns your tutorial, they can never take it cold again. So rotate. Keep a few trusted repeat testers for tracking whether fixes landed, but always feed in new people for the first-impression stuff, because first impressions are the only ones your launch players will ever have.
The one thing to do first
Before you write a survey, before you recruit a soul, do this: get one person who has never seen your game, sit them down, and watch them play the first five minutes without saying a single word.
You'll learn more from watching them fumble your opening than from a hundred "it was fun" replies. Everything else in this article is just how to do that at scale.
Common questions
How many playtesters do I actually need?
Fewer than you think for spotting big problems — a handful of fresh players will surface most of your worst issues, because the glaring stuff is glaring to nearly everyone. You need larger numbers only when you're tuning fine details like difficulty balance, where individual taste starts to matter and you need the pattern across many people.
Should I pay playtesters?
You don't need to for early, informal testing — genre enthusiasts and fellow developers usually test for the love of it or a swap. Paying becomes worth it when you want reliability, scheduled sessions, or people outside your natural audience who wouldn't show up for free. Just know that paid testers sometimes feel obliged to be positive, so watch behaviour over words even harder.
How do I test remotely if I can't sit next to someone?
Ask them to screen-share on a call and think aloud as they play, or have them record their session. The think-aloud narration is the remote substitute for watching their face — you're listening for confusion, hesitation, and the little "huh?" moments. It's not quite as rich as being in the room, but it beats any written survey.
What if testers give contradictory feedback?
That's normal and usually means you're hearing taste, not problems. When two people want opposite things, neither is necessarily wrong — look instead at what they agree on, which is often the underlying frustration dressed in two different outfits. Fix the shared problem and let the contradictory preferences cancel out.