How to Run a Beta Program Solo: A One-Person Playbook

To run a beta program solo, write down the single question the beta must answer and the criteria that end it, then invite 5 to 15 people who match your ideal customer. Run it for a fixed two to four weeks with one short weekly check-in, ask about what testers actually did rather than what they think, and close it on the date you set. Finish by reporting back and offering the testers who got value a founding price.

The rest of this guide is the detail: templates, a weekly schedule and the mistakes that turn a four-week beta into a six-month one.

TL;DR#

• Question first. One learning question and three to five exit criteria, written before the first invite.
• Small, matched group. 5 to 15 testers who fit your ideal customer, recruited by name, not by a public "sign up for beta" button.
• Fixed window. Two to four weeks with a start date and an end date that testers know about.
• Weekly pulse. One short message a week with the same three behaviour questions, plus usage you can see yourself.
• Close and convert. End on schedule, share what you changed, and make a founding-price offer.

Disclosure: ZeroRaised publishes this guide and is a launch site for bootstrapped products. The playbook is our editorial advice, not a published standard; the one external quotation comes from the GOV.UK Service Manual, checked on 6 Nov 2026. ZeroRaised has no commercial relationship with any organisation named.

Is this the right guide? Beta program vs soft launch#

If you are still deciding whether you need a beta at all, start with soft launch vs beta launch. That post defines the stages (private beta, open beta, soft launch, dark launch, full launch) and helps you pick one based on what you still need to learn.

This post assumes you have picked a private beta and are the only person who will run it. A team can split recruiting, support and analysis across people. You cannot, so the program has to be small, short and structured enough that it fits around building.

The GOV.UK Service Manual makes the same point about capacity for much larger teams. Its beta phase guidance says to make sure "the service team has the capacity to sustain that learning and iteration throughout the beta period" and that "support staff can cope with new users who might struggle to use the service, including in ways you have not foreseen" (checked 6 Nov 2026). When you are solo, you are the service team and the support staff, which is why every step below is sized for one person.

A beta is also not a waitlist. A waitlist before launch collects interest in something people cannot use yet. A beta is invited use of an unfinished product. Your waitlist is a good place to recruit beta testers from, but the two have different jobs.

Step 1: Write the learning question and exit criteria#

Most solo betas drift because nobody wrote down what would end them. Before you invite anyone, write one learning question. Good ones are specific and answerable in a few weeks:

• "Can someone in my target role complete the core job on their own data without my help?"
• "Does the weekly report replace the spreadsheet they use now?"
• "Which of the two onboarding paths gets people to their first result?"

Weak ones are vague or unanswerable: "Do people like it?" or "Is there demand?" A private beta cannot answer demand, because you picked the testers and they know it.

Then write three to five exit criteria tied to that question. For example:

Choose your own thresholds; what matters is writing them down before you see results. For the broader question of which criteria move you from beta to the next stage, the exit criteria section of the soft launch guide has a stage-by-stage table.

Step 2: Recruit 5 to 15 testers who match your ideal customer#

As editorial guidance, aim for 5 to 15 testers. Below five, one person's odd setup looks like a pattern. Above fifteen, a solo founder usually stops following up personally, and personal follow-up is the main thing a one-person beta does better than a big one.

Recruit by fit, not by enthusiasm. Write a one-line description of your ideal customer (role, situation, the tool or workaround they use today) and only invite people who match it. Friends who are not in the target group give kind feedback that tells you little.

Where to find them, roughly in order of quality:

1. People you have already talked to about the problem during validation.
2. Your waitlist, filtered by the answers they gave when they signed up.
3. Communities your ideal customer already uses, with a direct, specific ask and the rules of each community respected.
4. Warm introductions from early users or peers.

The outreach message should be short and explicit about the deal:

I am running a three-week private beta of [product], which helps [role] do [job]. I am looking for 10 people who currently [do the job with workaround]. It takes about [realistic time] a week: use it for real work and answer three short questions each Friday. The beta ends on [date]. Testers get [founding price or other benefit] if they want to keep using it. Interested?

Stating the end date and offer up front makes the conversion step feel like keeping a promise, not a pitch. The tactics overlap with getting your first 10 paying customers, and the best testers often become exactly those customers.

Step 3: Set up the minimum operating kit#

You do not need dedicated beta software. You need five things, and most founders already have them:

• An access gate. An invite code, an allowlist of emails or a feature flag, so only invited testers get in.
• A known-issues note. One page listing what is broken or missing, so testers do not report the same thing ten times.
• One feedback channel. Email, a shared chat channel or a form. Pick one; three channels means three inboxes to check.
• Basic product analytics. Enough to see who logged in, who reached the core result and where they stopped. Behaviour you can observe beats behaviour testers remember.
• A tracking sheet. One row per tester: segment, start date, last active, core job completed (yes/no), themes raised, conversion outcome.

Decide whether tester data carries over when the beta ends, and tell testers up front.

Step 4: Run a fixed two to four week window#

Pick the length from how often the product is meant to be used. A tool used every day shows its value in two weeks. A weekly or monthly workflow needs closer to four, so testers get at least a few real cycles. Put the start and end dates in the invite, the welcome email and the known-issues note.

A schedule that fits around building:

Keep builds stable. Shipping every day means testers keep hitting new bugs, and you cannot tell which version caused which feedback. One planned release a week, announced with a short note, is easier to learn from.

Block a fixed each-day slot for beta support and a weekly one for reading the pulse. Outside those slots, build.

Step 5: Send a weekly pulse, not a stream of surveys#

The weekly pulse is the heartbeat of a solo beta. It is one short message, sent on the same day each week, with the same questions, so answers are comparable across weeks.

Three questions are enough:

1. "What did you use [product] for this week, if anything?"
2. "Where did you get stuck or give up?"
3. "What did you do instead, or what would you have done if [product] did not exist?"

Pair the replies with what your analytics show for that tester. If someone says they used it a lot but logged in once, trust the log and ask a gentle follow-up.

Testers who go quiet are data too. One nudge is fair; after that, record them as inactive and note it in your tally. Silence from a well-matched tester often means the product did not earn a place in their week, which is an answer to your learning question.

Step 6: Ask behaviour questions, not opinion questions#

Opinion questions invite politeness. Behaviour questions invite facts. The difference decides whether your beta produces evidence or compliments.

For the close-out interviews, pick three to five testers: the most active, the least active and at least one who got stuck. Keep each call short, ask them to share their screen and do a real task, and say as little as possible while they do it. Write up notes the same day.

Log feature requests, but look for the problem behind each one rather than treating it as an instruction.

Step 7: Close on schedule and convert#

On the end date, close the beta. This is the step solo founders skip most often, because closing forces a verdict. Compare what you learned against the exit criteria you wrote in Step 1 and record, in one line each, which passed and which failed.

If the criteria passed, move to the next stage. If they did not, write down which one failed and what you will change, and decide whether a second, short round with a few new testers is worth it. Either way, the original beta ends.

Then send two emails.

The close email goes to everyone. Thank them, tell them what you learned and what you changed because of their feedback (specific changes, not "lots of improvements"), say what happens to their account and data, and give the date the product moves to its next stage.

The conversion email goes to testers who reached the core result. Make the founding-price offer you promised at the start, with a clear deadline and a direct payment link. Keep the terms simple and honest: what the price is, how long it is locked for and what they get. Do not pressure testers who did not get value; their "no" is useful information about fit.

Whoever pays is the most reliable signal the beta produced. Whoever declines, ask one question: "What would have needed to be true for this to be worth paying for?"

Common mistakes in a solo beta#

• No end date. The beta becomes a permanent free tier and nobody ever pays.
• Too many testers. You stop replying personally, response quality drops, and you are running support instead of research.
• Wrong testers. Friends and fellow makers who are not your customer give encouraging, unrepresentative feedback.
• Building every request. The product grows sideways and the core job never gets sharper.
• Skipping the conversion offer. You never find out whether the value was real enough to pay for.

Once the beta closes and you are preparing the wider release, work through the product launch checklist for bootstrapped makers, which covers billing, trust pages, launch assets and release-day support.

Frequently asked questions#

How many beta testers does a solo founder need?#

As editorial guidance, 5 to 15 people who match your ideal customer. Fewer than five makes it hard to tell a pattern from one person's habits; more than fifteen usually means you cannot follow up with everyone personally, which is the main advantage a solo founder has.

How long should a solo beta program run?#

Set a fixed window of two to four weeks before you invite anyone. Two weeks suits a tool used every day; four suits something used weekly. If the question is not answered by the end date, write down which exit criterion failed and decide whether to run one more short round, rather than leaving the beta open.

Should beta testers pay?#

Not during the beta itself, unless your learning question is about willingness to pay. Instead, tell testers at the start that the beta ends on a set date and that they will be offered a founding price. Whether they take that offer is the most honest signal the beta produces.

What questions should I ask beta testers?#

Ask about behaviour: what they tried to do, where they got stuck, when they last had the problem, what they used instead and what happened the last time they opened the product. Avoid opinion questions such as whether they like it or would recommend it, because polite answers tell you little.

What is the difference between a beta program and a soft launch?#

A beta gives a chosen group access to an unfinished product in exchange for feedback. A soft launch sells the finished product at its real price with little promotion. ZeroRaised's soft launch vs beta launch guide covers how to choose the stage; this guide covers how to run the beta once you have chosen it.

Where ZeroRaised fits#

ZeroRaised is a free launch site for products built without institutional VC or accelerator equity. A private beta is not the moment to list, because the product is not open to the public yet. Once your beta has closed and the product is publicly available, you can submit it for review. If you want our next guides on launching, pricing and selling without investors, join the ZeroRaised newsletter.

A listing works best after the beta has told you who the product is for, because that is what the listing has to say.

Sources#

• GOV.UK Service Manual: How the beta phase works, checked 6 Nov 2026
• ZeroRaised: Soft launch vs beta launch, checked 6 Nov 2026
• ZeroRaised: How to build a waitlist before launch, checked 6 Nov 2026
• ZeroRaised: Product launch checklist for bootstrapped makers, checked 6 Nov 2026
• ZeroRaised: How to get your first 10 paying customers, checked 6 Nov 2026