Quick answer: Recruit 20–50 strangers (not friends), distribute via Steam Playtest, run the alpha for 1–2 weeks with a clear "what to look for" document, use a structured feedback form plus free-form channels, and triage all feedback into a single backlog before deciding what to fix. Your goal is validating the core loop, not polishing.

There is a moment in every indie game's development when the person writing the code has to watch someone else play it. It is terrifying, it is embarrassing, and it is the single most valuable thing you can do before shipping. A closed alpha is the first structured version of that moment: a small, private group of strangers play your game for a week, tell you what broke and what confused them, and you fix the important ones before opening the gates to a wider beta. Here is how to run one that actually produces useful data.

What a Closed Alpha Is For

The purpose of a closed alpha is to answer three questions:

  1. Does the core loop work for people who are not you? You have played your game 500 hours. A new player bounces off in 5 minutes. Alpha tells you whether the early experience is working.
  2. What obvious bugs exist that you cannot see? You have internalized every workaround and known quirk. Fresh players hit the walls you learned to walk around.
  3. What is the feeling of playing this? Is it fun for 30 minutes? An hour? Three hours? Do they want to come back tomorrow?

It is not a place to polish UI, tune balance, or validate monetization. Those come in beta. Alpha is for finding the bugs and confusions that would embarrass you in front of strangers.

Step 1: Recruit Strangers, Not Friends

Friends and family will lie to you. They will say the game is great because they love you. Strangers have no social reason to be kind, and their honest reactions are what you need.

Good sources of strangers:

Aim for 20–50 accepted testers. Below 20 and you get thin data; above 100 and the feedback volume overwhelms a solo developer. If you run at the 50 end of that range, expect 15–25 who actually play enough to give feedback.

Step 2: Screen Applicants

A one-page application form weeds out people who will not finish and identifies testers who match your target audience. Ask:

Mix genre-experienced testers with genre-curious ones. Pure veterans give you hardcore design feedback; curious newcomers give you onboarding feedback. Both matter.

Step 3: Distribute Builds via Steam Playtest

The professional indie solution is Steam Playtest, a free feature that lets you gate access to a separate Playtest appid via keys or direct request-join. Benefits:

The alternative for Mac/Linux or non-Steam testers is itch.io with password-gated downloads. Avoid zipping builds and emailing them — within three days your testers will be on five different versions and you will not know who is reporting what.

Step 4: Write a "What to Look For" Document

Testers will give you better feedback if you tell them what you want to learn. A one-page document sent with the build invitation sets expectations:

What we want you to focus on:
- The first 30 minutes (the onboarding/tutorial)
- Whether the core loop makes sense
- Any bugs that block progress
- Any UI text that is confusing

What we are NOT testing in this alpha:
- Art polish (we know it is rough)
- Audio balance (we will tune later)
- Performance on high-end hardware (we know it is fine)
- Steam achievements (not implemented yet)

How to report a bug:
- Press F8 in-game to open the bug reporter
- Or post in #alpha-feedback on Discord
- Include what you were doing and a screenshot if possible

Timeline:
- Alpha runs Apr 12 - Apr 26
- Feedback survey link closes Apr 28
- We will share what we learned publicly after that

This document does three jobs: it tells testers what is worth reporting, it lowers their anxiety about "bothering you" with minor issues, and it manages expectations so they do not submit 40 bugs about placeholder art.

Step 5: Give Multiple Feedback Channels

Different testers prefer different feedback styles. Provide:

The in-game reporter catches specific bugs. Discord catches the "this feels weird" vibes. The survey captures structured data you can analyze. Interviews catch deep insights that no survey question can pull out.

Step 6: Make Fixes Visible

Testers who see their feedback get acted on will give more feedback. Publish a daily or every-other-day changelog in the tester Discord:

Alpha Build 0.4.2 (Apr 14)
- FIX: Crash when saving in the forest area (reported by @alice)
- FIX: Tutorial arrow pointing to wrong button (reported by @bob, @charlie)
- NEW: Added a "skip tutorial" option (requested by multiple testers)
- KNOWN: The boss room is still placeholder art, we know

Credit the specific testers who reported each fix. It takes 30 seconds and turns testers into evangelists who will tell their friends how great your playtesting experience is.

Step 7: Triage All Feedback Into One Backlog

By the end of the alpha, you will have feedback scattered across Discord, bug reports, surveys, and email. Consolidate it into one place — a spreadsheet, Notion, or your bug tracker — with these columns:

Sort by severity. Fix every blocker. Fix every bug reported by three or more testers (even if each individual report is minor — the cluster is the signal). Defer everything else to beta.

Step 8: Close the Loop Publicly

At the end of the alpha, write a post-mortem dev log:

This becomes marketing for your beta and builds trust with your audience. A developer who runs a transparent alpha is a developer people want to buy from.

"The most painful hour of my development cycle was watching the first alpha tester try to launch my game. The most valuable hour was the same one, because I saw every broken assumption in my UI in under ten minutes."

Related Issues

For the broader beta test process after alpha see how to run a beta test for your indie game. For how to recruit from a community you already have, read building a community beta testing program.

Watching your first alpha tester is the hardest and best part of development. Do not flinch.