How to run a beta launch: a one-page plan

Most advice on beta launches assumes a team: a program manager, a feedback tool, hundreds of testers and a quarter to run it. If you are one person with forty names on a list, almost none of that applies. What does apply is simpler, and it is mostly decisions you make in an hour, before the beta opens.

This guide covers running the beta. If you still need to recruit testers, my guide to finding beta testers lists where to look, and I will not repeat it here. Everything below assumes you have a few names and need to turn them into answers. It sits inside the bigger job of getting your first 100 users.

What is a beta for, and what one question must it answer?

A beta exists to answer one question you cannot answer by yourself. That is the whole definition. "Does it work?" is not a question, because you can test that alone. "Can a stranger finish setup without asking me anything?" is a question, because only a stranger can tell you.

Pick the question that scares you most. For most solo products it is one of three: can someone get to the first result unaided, do they come back a second time, or will they pay or switch from what they use today. Each needs a different group and a different window, which is why you cannot run a beta for all three at once. Write the question in one sentence. If it has an "and" in it, split it into two betas and run the first one first.

Private beta or public beta: which one does your question need?

Use a private beta when the question is about the first experience, and a public beta when the question is about demand or load. The distinction is old and well documented. The UK government's service manual on the beta phase describes private beta as inviting a limited number of people so you can get feedback and make improvements, then opening to anyone once you are confident the service can run at scale. That order works just as well for a one-person product.

If you already have a list of interested people, a waitlist is the natural source for a private beta. Invite the people who replied to your emails first, not the ones who only clicked.

How many beta testers do you need?

Fewer than you think, and you should invite more than you need. Those two facts fit together. The number you need is the number who actually use the product. The number you invite has to cover everyone who says yes and never opens it, and that is often more than half.

On the need side, the Nielsen Norman Group's long-running argument is that testing with about five users per round finds most of the usability problems worth fixing, and that several small rounds beat one large one. You are not running a statistical study. You are looking for the same obstacle appearing for the third person. Ten to fifteen people who really try it will show you that.

A workable rule: decide how many active testers you want, then invite about two and a half times that. For twelve active testers, invite thirty. If your product needs an app store gate, such as a minimum tester count on a closed track, check the platform rules first, because they can set a floor. The pre-launch feedback guide covers how to ask for feedback that is specific enough to act on.

How long should the beta run, and what are the exit criteria?

Two to four weeks, with the end date announced in the invitation. The length matters less than the fact that it is fixed. A deadline gives testers a reason to act this week, and it gives you permission to stop. Without one, a beta drifts for months while you wait for a clean result that never arrives.

Exit criteria are the second half of the same discipline. Write them before the first invite, as a number plus a condition: for example, eight of twelve testers finish setup unaided, and no open bug blocks setup. When the window closes you compare the result to the criteria. You do not get to decide afterward that it felt good enough. If you hit them, you launch. If you miss, you know exactly what to fix, and you run a short second round rather than extending the first.

How do you run the beta week to week?

Keep the cadence light and fixed: a welcome on day one, a nudge around day four, a direct reply or short call around the midpoint, and a wrap-up near the end. Four touches. Testers who hear from you daily start to feel managed, and testers who never hear from you forget you exist.

Ask about behavior, not opinion. "What did you try first?" and "Where did you get stuck?" produce facts. "Do you like it?" produces politeness. Three questions cover most of what you need:

• What did you try to do, and did you get it done?
• What was the first thing that confused you?
• Have you used it again since, and if not, what got in the way?

The third question is the most valuable one in the whole beta, because a second visit is the behavior that predicts whether the product sticks. Keep a simple log of every complaint and tally how many different people raise the same one. Two people hitting the same wall is a signal. One person hitting a wall is an anecdote. Resist the urge to build new features mid-beta. Fix blockers, record requests, and save the rest for after you close.

How do you close the beta and turn testers into users?

Close it on the date you promised, with a personal message to each tester. Say what you learned, name one thing you changed because of their feedback, thank them by name, and make the conversion offer in the same note. Decide the offer before the beta ends, so the thank-you and the invitation arrive together instead of two weeks apart.

Good offers are simple: early access pricing, a discount for the first year, or free until launch day. Do not make testers do anything clever to claim it. Also ask each person for a short testimonial or review while they remember the experience. The same reasoning as in the week after a launch applies: the people who just helped you are the warmest audience you will have. Then compare results against your exit criteria, write the outcome in one honest paragraph, and move to launch or to a short second round.

The one-page beta plan, filled in

Here is the whole beta on one page. Copy the left column into a note, fill in your own answers, and do not send a single invite until every row has one. The example column shows a plan for a small SaaS tool with a 14-day private beta.

If you want company while you run it, Favors.dev is built for this stage. Members earn points by leaving honest, verified feedback and reviews on each other's products, so a beta can include testers who reply because the points economy rewards a useful answer. Check the launch calendar to see who else is about to ship and trade a favor with them.

Frequently asked questions