How to Turn Your Waitlist into a Beta Program (2026)

A waitlist and a beta program are two different things and most indie founders collapse them into one. The waitlist captures interest; the beta program captures usage. Skipping the beta and going straight from waitlist to public launch is how founders end up with 2,000 signups, 100 customers, and no idea which onboarding step lost the other 1,900. This is the beta-program shape I now run between the waitlist and the public launch.

I have shipped 7 indie apps over 8 years and ended up building two tools for myself along the way: Spaceport, a SwiftUI starter that gets a paid iOS app live in days, and Lighthouse, the launch toolkit this post is mostly about. The beta shape below is what both products run before a public launch email goes out.

Table of contents

• Why a beta program, not just a launch
• Who to invite from the waitlist
• The invitation email
• What to ask them to do
• Collect feedback in one place
• What to fix, what to note
• Graduate beta users to paying
• Frequently asked questions

Why a beta program, not just a launch

A launch email fires once and tells you nothing about what is actually broken. The public launch is when the copy, the onboarding, and the pricing all get tested at the same moment, and if any of the three is off, the launch just shows you the composite failure, not which one caused it.

A beta program between the waitlist and the public launch is the missing debug step. Fifty engaged people use the thing for a week, tell you what stopped them, and let you fix the two or three onboarding issues before you push the button on the launch email. It costs you three weeks. It usually doubles the conversion rate of the launch that follows.

Who to invite from the waitlist

Not the whole list. A beta program with 500 people is a support crisis, not a debug step. Pick 30 to 100, weighted toward the signups most likely to actually use the thing. Three signals worth reading:

• Survey answers that name the pain. If your waitlist form asked “what have you tried?” or “how do you handle this today?”, the people who wrote a full paragraph rather than one word are the ones with the strongest existing pain. Those are your betas. For why answers on the signup form matter, see why answers beat emails.
• Recent signups. A signup from last week is more likely to remember why they signed up than one from six months ago. If you have to pick between an old detailed answer and a recent short one, take the recent one.
• Replies to your warmup emails. If you sent a warmup email that ended “reply with the biggest thing you want this to do for you”, the people who actually replied are self-identified betas. Invite them first.

Aim for 30 to 100 invitations, expect roughly a third to actually show up and use the product. The math: 60 invitations, 20 active betas, 15 useful pieces of feedback, 5 changes that ship. That is a healthy beta.

The invitation email

The invite is not a launch email. It is a small ask to a specific person, and it should read like it. Short, personal, with a real reason they were picked:

One link, one ask, one specific reason they were picked. The reason is what pushes accept rates from 15 percent to 40 percent; a generic “come try the beta” email reads as a mass send even when it is not.

What to ask them to do

“Try it and let me know what you think” produces almost no useful feedback. Betas are polite; they will tell you it looks nice and never come back. A specific ask produces a specific answer:

• One task, named clearly. “Set up your first training plan and complete one run against it.” Or “Import your existing subscriber list and send one campaign.” The task should be the core value moment of the product.
• A deadline that is short. One week, not one month. Long betas drift; short betas get the task done.
• A promise about their feedback. “I read every reply and ship fixes within 48 hours.” Betas write more when they know it lands somewhere.
• An escape hatch. “If you decide this is not for you, one-click unsubscribe. No hard feelings.” Removes the guilt friction that keeps silent betas silent.

Collect feedback in one place

The failure mode most indie betas hit is that feedback ends up in five channels. Some in DMs, some in a Google Doc, some in reply emails, some in a Notion page, some in a Discord. You forget which channel a comment came from and the same piece of feedback gets addressed twice or lost.

Pick one place and put a link to it in the beta invite. A public feedback page (like Lighthouse's feedback page, or a dedicated feedback tool) works well because betas can see what has already been reported and upvote instead of adding a duplicate. For where dedicated feedback tools fit (Canny, Featurebase, Nolt), see best product feedback tools.

If a beta emails you directly (they will), copy the message into the feedback board yourself and reply to them with the link. Two rounds of doing this and they start posting directly.

What to fix, what to note

The instinct in a beta is to fix everything. Do not. A two-week beta is a signal-collection exercise, not a feature-shipping one. Sort every incoming piece of feedback into three buckets:

• Ship this week (broken). The user cannot complete the core task. Sign-in fails, the app crashes, the button does not do what it says. Fix within 48 hours. This is the highest-value signal a beta gives you and the reason the beta exists.
• Ship before public launch (friction). The user can complete the task but three of them tell you the same step was confusing. That is copy or onboarding friction that would tank the public launch. Ship it before the launch email fires.
• Note for later (real feature). A single beta wants a new capability that would take four weeks to build. Note it, tell them thanks, do not build it. Betas ask for the moon; the launch does not need the moon.

The three-bucket rule keeps the beta a debug step and protects the timeline. Turning every “wouldn't it be nice if...” into a shipped feature is how a two-week beta becomes a three-month one.

Graduate beta users to paying

The beta ends with a graduation email. Betas do not automatically become customers; you have to ask, and the offer has to reward the time they gave you:

• Name what shipped because of them. “You asked for X, Y, and Z. Y shipped Tuesday, X shipped this morning, Z is on the list.” This is the highest-trust moment of the whole launch arc; do not waste it on a generic thank-you.
• Give them a real perk. First three months free, or a lifetime charter price, or an extended trial. Not a 10 percent discount code that reads like a generic promo. The perk should feel like a gift, not a marketing tactic.
• One link, one ask. Same shape as the public launch email but personalised. See how to write your first launch email for the shape; the graduation email is the same shape with a longer opening paragraph naming their specific contribution.

Beta graduation typically converts at 40 to 60 percent (versus 8 to 12 percent for the general waitlist launch). The people who used the product for a week already know it works for them; the graduation email removes the “should I pay” friction. For the full waitlist-to-paying playbook including the follow-up sequence, see how to convert waitlist signups into paying customers.

Frequently asked questions

How long should the beta actually run?

Two weeks for a SaaS with a short value moment (sign up, do the thing, get the answer). Three to four for a product with a weekly cadence (training plans, newsletters, habit-tracking). Longer than four weeks and betas forget they are in a beta.

Should I charge during the beta?

Not for the first beta. Betas are trading time for the product; asking them to pay too changes the deal and filters out honest feedback. Charge at graduation, with the perk that recognises the time they gave you.

What if I am raising alongside running a beta?

The beta and the raise run on different tracks. Betas care about the product; investors care about traction, growth signals, and thesis fit. Dedicated platforms like Funding Banker, a curated investor directory with pitch and outreach tracking, handle the investor side. Do not put investors in the beta; they are looking at the wrong signal for the wrong reason.

What if nobody accepts the beta invite?

Accept rates under 15 percent usually mean the invitation was too generic. The fix is not more invitations; it is re-writing the invite with a specific reason each beta was picked. Ten hand-written invitations with a real reason beat 100 template sends.

How does this fit the rest of the launch arc?

The beta sits between the waitlist warmup and the public launch email. For the full sequence (warmup, launch, follow-up), see how to convert waitlist signups into paying customers. For the twelve-step pre-launch shape the beta fits into, see the pre-launch checklist for an indie SaaS.

The beta program is small on purpose: 30 to 100 invitations, 20 active users, two weeks. Its job is to debug the launch before the launch happens. Skip it and the public launch becomes your debug step, which is a worse deal for everyone.

Lighthouse handles the waitlist that fills the list, the newsletter that runs the invitations and the graduation, and the feedback page for the beta, in one place. Free trial, indie pricing. From the same indie dev behind Spaceport, a SwiftUI starter kit for shipping paid iOS apps fast.