How to get beta users for your startup

You built your SaaS, and you need real people to use it before you open it to everyone. This guide shows how to get beta users for your startup who have the problem, use it on real work, tell you the truth, and then pay. A "looking for beta testers" post and a few messages to friends bring polite praise and nobody logging in; 100 invites a day and a beta with an end date bring you your first customers.

Do these three things

About 5 hours a day, every day. Aim for 20 active beta users. Judge the invites after 1,400 messages and the beta at the end of week 4.

Show the three actions in fullHide the full list

1. 1Today: write a 4-week beta deal: who your SaaS is for, what each beta user does every week, the end date, and the founding price after it. Put it on one page with a 4-question application form.
2. 2Every day: send 100 personal beta invitessoon and 20 helpful answers in places where your buyers ask for helpsoon, to people who have the problem now. AI drafts; you add one true line. Set up every accepted beta user on a 20-minute call within 48 hours and watch them use it.
3. 3Every Sunday: count who used it this week, send each beta user 3 questions, and fix the one problem most of them hit. At the end of week 4, ask every active beta user to pay.

Get help doing these

ChatGPT or Claude reads this guide and works through it with you.

Do this with ChatGPT(opens in a new tab)Do this with Claude(opens in a new tab)

1. Write a 4-week beta deal with an end date and a price#

A beta user is someone who has the problem your SaaS fixes and agrees to use it on real work for a set time, and to tell you what happened. Write that deal down before you invite anyone: who it is for, what they do each week, when it ends, and what it costs after.

The deal is what makes people show up. Without it, a beta is "try it and let me know", and most people never do. In May 2026, Bessemer Venture Partners put it plainly: "Indefinite free access is an advisory relationship, not a validation signal." Their advice for early customer groups is a fixed timeline, regular feedback, a lower price during the program, and a hard date to pay or leave.

First, check that a beta is the right job. If your SaaS is already public and people are signing up, you do not need a beta. You need your first 100 users instead: people who signed up and did the main thing. If you cannot name 20 people who have the problem, check that people really want it before you recruit anyone.

Then fill in the deal. Take "who it is for" from your ideal customer profile, and the problem in the words people used in your customer interviews. Pick the one main job the beta tests: the action that shows your product did its job, like the first report sent. That is your activation point.

Aim for 20 active beta users: people who do the main job at least once a week. If you want the survey at the end (step 7) to mean something, aim for 40. Run the beta for 4 weeks. Invite new people every day until you have 20 active, so later people start later and finish later.

Set the founding price now, so nobody is surprised at the end. It is lower than your normal price, and it only goes to people who finish the beta. If you have not set a normal price yet, set it first. The whole routine takes about 5 hours a day, so make room for it before the first invite goes out.

Who it is for: [kind of team] of [size] who [the moment the problem hurts].The one thing we are testing: can you [the main job] on your own real work?What you do:
One 20-minute set-up call with me in your first 2 days.
Use it on real work at least once a week, for 4 weeks.
Answer 3 short questions by email every Sunday.
What you get:
My direct email, and a reply the same day.
What you tell me decides what I build next.
After the beta: [founding price] for [how long], instead of [normal price].
The beta ends on [date]. Then I'll ask if you want to keep it at the founding price. No card needed until then.

• Tool: a Google Doc. Free.
• Time: 45 minutes.
• You will have: a one-page beta deal with a who, a main job, a 4-week end date and a founding price.
• It worked if: you show it to one person who has the problem, and they can say what they would do each week and what happens at the end.
• Common mistake: an open beta with no end date and no price, where "anyone can join". It fills with friends and other founders who never have the problem, and it ends with nobody paying.

2. Make a beta page with a 4-question application form#

Put your beta deal on one page with an "Apply for the beta" button. The button opens a short form that lets in only people who have the problem now.

The page needs five things, top to bottom. The headlinesoon: the result, and who it is for, in your buyer's words from your value proposition. The deal from step 1. The start and end dates. How many places are left. The apply button. That is a small landing pagesoon; a new page on your own site is fine.

Make the form in Tally. Its free plan has unlimited forms and unlimited submissions, and it can send answers to a Google Sheet. Google Forms works too. Ask four questions, plus name, email and "Where did you hear about the beta?", so you know which place each applicant came from. This is self-reported attribution.

What do you use today to [do the job]?
When did [the problem] last happen to you, and what did it cost you?
What is your role, and how many people are on your team?
Will you do a 20-minute set-up call this week and use it on real work for 4 weeks? (Yes / No)
Name · Email · Where did you hear about the beta?

Accept anyone who had the problem in the last 30 days and answered "Yes" to question 4. Reply to every application within 24 hours, from your own email: accept them with your booking link (step 5), or say no kindly and offer to write when you launch. Fast replies matter: the person applied while the problem was on their mind.

If you already have a waitlistsoon, email everyone on it the beta page today. They are your first applicants.

• Tool: your site editor, and Tally (free plan) or Google Forms.
• Time: 1 hour 30 minutes.
• You will have: a live beta page and a form that fills a sheet.
• It worked if: a test application lands in your sheet, and 3 people who have the problem can say, after reading the page, what the beta asks of them.
• Common mistake: a 15-question form, asking for a card, or a "join the waitlist" button with no date. People who fill in a long form for nothing stop there.

3. Send 100 personal beta invites a day to people who have the problem now#

Send 100 one-to-one beta invitessoon every day, starting with people who have the problem right now. Each invite asks one thing: will you apply for the beta?

Public posts asking for beta testers bring almost nothing now. We counted the 17 Hacker News posts in 2026 with "beta test" in the title: 11 got no comments at all, and none got more than 3. What works is asking people one at a time. In June 2026, a founder on Hacker News asked how to get beta testers. One answer: "Find people on Reddit or competitor forums that struggles with the issue you are solving and ask them if they want to try."

Work down your list in this order:

• People you know who have the problem. Past colleagues, clients, friends at companies like your buyer. This is warm outreach. Export your LinkedIn connections and mark who has the problem.
• People who had the problem in the last 30 days. Search subreddits, forums and LinkedIn for posts about the problem, sorted by new. Read the bad reviews of the tools you compete with; your competitor analysis list is a good start. Someone who complained last week is the best beta user you can find.
• People who fit your profile. Add them to your lead listsoon and find the right emailsoon. 100 a day needs about 3,000 names a month, so add 100 new names every day.

Let AI do the drafting. Paste 10 people at a time into ChatGPT or Claude, each with the thing they wrote or did, plus your beta deal. Ask for one short invite per person. Read each one, make the first line true and about them, then send. That is about a minute an invite. Follow upsoon with everyone who has not replied, twice, 3 days apart, with one new line each time. Stop the moment someone says no.

Keep every invite one-to-one and inside the rules. Gmail requires every sender to have SPF or DKIM, and to keep spam reports below 0.3%. If you email more than about 50 strangers a day, set up a second domainsoon and warm it up first. LinkedIn limits connection invitations, and a block usually lasts one week, so on LinkedIn message people you are already connected tosoon and send the rest by email. In the US, the CAN-SPAM Act covers business email: each message needs your postal address and a way to say no, and you must honour a "no" within 10 business days. The UK and EU have stricter rules on emailing people, so check them first and lean more on people you know and on step 4.

Subject: [the problem, in 3–5 words]Hi [first name],[One true line: what they wrote, posted or did about the problem.]I've built [product] for [kind of team] who [problem]. Before I open it to everyone, I'm running a 4-week beta with 20 teams.You'd get a 20-minute set-up call with me and a say in what I build next. I'd ask you to use it on real work each week and answer 3 questions on Sundays.Want a place? Apply here (2 minutes): [beta page link][Your name]
[Your company, postal address]
Not for you? Reply "no" and I won't write again.

• Tool: Gmail or LinkedIn, ChatGPT or Claude to draft, and your sheet. A CRMsoon can wait.
• Time: about 2 hours a day for invites and follow-ups, and 45 minutes to find 100 new names.
• You will have: 700 invites sent and logged each week.
• It worked if: you get at least 3 applications from every 100 invites. Start with that number and replace it with your own after 300 invites. Below 2, rewrite the first linesoon so it is more about them, then send the next 100.
• Common mistake: "Hey, want to check out my beta?" with a link and nothing else. It gives no reason and no ask. The other mistake is sending the same text to hundreds of people from a bulk-sending tool. That is spam, and it lands in spam.

4. Answer 20 questions a day and post your beta only where it is allowed#

Pick 5 online places where your buyers ask for help with the problem. Answer 20 questions a day across them, and post your beta call only in the threads or on the days each place allows it.

A place can be a subredditsoon, a Slack or Discord group, a forum, or a Facebook groupsoon, as long as your buyers ask questions there. Use the same reply method as for any SaaS: search for the problem, sort by new, answer the question in the first line, and give 2–3 steps that work without your product. Write each answer in your own words. Use AIsoon to find questions and list points, not to write the reply.

Read each place's rules on self-promotion first. Reddit's own rule is to "participate authentically in communities where you have a personal interest, and do not spam". Many places keep project posts to one weekly thread. Post your beta call once in each place, in that thread. Add UTM parameterssoon to the beta page link, so you can see which place sent each visit. If someone in an answer thread asks what you use, say you are building a tool for it, and give the beta page.

Be careful with beta sites and beta-tester subreddits. The people there mostly build products themselves, so they test yours as a favour, not because they have the problem. BetaList no longer has a free option: all submissions are paid. If you use one of these, post once, count only applicants who pass your form, and do not count it as one of your 5 places.

Do not launch on Product Hunt or Show HNsoon during the beta. A launch works best once people already use and pay for your product. Launch after step 7.

[Product]: [the result] for [kind of team].I'm looking for 20 [kind of team] for a 4-week beta, ending [date]. You get a 20-minute set-up call with me and a say in what I build. I ask you to use it on real work each week and answer 3 questions on Sundays.Only apply if [the problem] happened to you in the last month: [beta page link]

• Tool: the search box on each site.
• Time: about 1 hour a day, 3 minutes an answer.
• You will have: 140 useful answers a week, and one beta call in each place that allows it.
• It worked if: after 560 answers (4 weeks), at least 5 applications say they came from one of these places.
• Common mistake: posting "Looking for beta testers!" in every group you can find. Moderators remove it, and the people who do reply are mostly other founders.

5. Set up every beta user on a 20-minute call within 48 hours and watch#

Within 48 hours of accepting someone, get them on a 20-minute call where they do the main job on their own real work while you watch. This is how you get people to really try your product past day one, and how you see what is wrong.

Watch, do not ask. People are not good at telling you what would work better. In January 2026, a founder asked on Hacker News how to find beta testers who give useful feedback. The reply: "Users are unlikely to accurately describe what would work better." You learn more from watching one person get stuck than from ten opinions.

Make a booking page first. In Google Calendar, click Create, then Appointment schedule, and set 20-minute slots. The basic booking page works on a free Google account. Send it in your acceptance email.

On the call, ask them to share their screen and do the main job on one real piece of their own work. Then stay quiet. Do not take over or explain the screen. When they stop, ask "What are you looking for?" and write down their exact words. Help only when they are truly stuck, and write that down too. This is not a product demosoon; they do the work.

Fix between rounds. A 2000 study by the Nielsen Norman Group found that testing with 5 people finds about 85% of usability problems. So after every 5 calls, fix the place where most people stopped before the next 5. After each call, paste your notes into ChatGPT or Claude and ask it to sort them into "got stuck", "asked for" and "liked". Check the sort yourself. This is where raising your activation ratesoon starts, and it shapes your onboarding emailssoon later.

Subject: you're in the [product] betaHi [first name],You're in. Thanks for applying.First step: pick a 20-minute slot in the next 2 days: [booking link]. Bring one real [piece of work] you'd use it on. You'll share your screen and do it yourself; I'll help if you get stuck.The beta runs until [date]. Each Sunday I'll email you 3 short questions.My direct email is this one. Reply any time.[Your name]

• Tool: Google Calendar appointment schedule, Google Meet, and your sheet. All free.
• Time: 30 minutes per beta user: 20 for the call and 10 for notes.
• You will have: every beta user has done the main job once, and a list of every place people stopped, in their words.
• It worked if: at least 3 in 4 beta users do the main job on the call. If fewer do, fix the first place most people stop before the next call.
• Common mistake: doing a demo while they watch, or taking control of their screen. They leave knowing it works for you, and never do it alone.

6. Check on quiet beta users every day and count who used it every Sunday#

Every day, send a personal note to any beta user who has not done the main job in 7 days. Every Sunday, send each beta user 3 questions, count who used it, and pick the one problem to fix this week.

People who go quiet in a beta almost never come back on their own, the same way trial users churnsoon without telling you. A short note from you, sent the day they go quiet, is how you find out why. The answer is usually more useful than anything a happy user says.

Every day: look at the last date each beta user did the main job. Your own database or your product analyticssoon can show it. Anyone at 7 days gets a personal note: "I noticed you haven't used it this week. What got in the way?" Log what they say.

Every Sunday: email each beta user the same 3 questions. Keep it to 3, and let them answer by replying. Then fill in one row in your sheet: how many beta users did the main job this week, what they said, and the one problem most of them hit. Fix that one problem this week, and tell the people who raised it when it is fixed. People keep giving feedbacksoon when they see it change something.

Build a feature only when 3 or more beta users ask for the same thing. One person's request is a note in the sheet, not a week of work.

Subject: 3 questions, week [N] of the [product] betaHi [first name],
What did you use [product] for this week?
What stopped you, or annoyed you?
If [product] went away tomorrow, what would you do instead?
Reply here, a line each is plenty. This week I fixed: [the fix, in one line].[Your name]

• Tool: your product's last-active dates, your sheet and your email.
• Time: 20 minutes a day, and 1 hour each Sunday.
• You will have: one row a week: active beta users, the top problem, and the fix.
• It worked if: at least half of your beta users do the main job each week. If fewer do, stop inviting for 2 days and fix the step where most people stopped (step 5).
• Common mistake: building every feature someone asks for. The beta turns into a to-do list for 20 different people. The other mistake is only listening to the people who reply. The quiet ones tell you the most.

7. End the beta on the date and ask every active beta user to pay#

On the end date, ask one question to find out how much people would miss your product. Then ask every active beta user, one by one, to keep it at the founding price.

First, ask the question Superhuman made famous: "How would you feel if you could no longer use [product]?", with the answers "Very disappointed", "Somewhat disappointed" and "Not disappointed". Send it only to people who used it at least twice in the last 2 weeks. In 2018, Superhuman's founder wrote that products which kept growing almost always had more than 40% of people answer "very disappointed". This is a signal of product-market fit. Their team said results start to point the right way at about 40 answers, so with 20 beta users, read it as a hint, not a verdict.

Then ask each active beta user to pay. Send a personal message, not a link to your pricing pagesoon. Give the founding price, what it includes and the date it starts. Offer a 10-minute call to anyone who is unsure. Beta users who had a good first month are far more likely to pay after a trialsoon than strangers. Those who say "very disappointed" get two more asks: one sentence you can quote on your site, your first testimonialsoon, and one introductionsoon to someone with the same problem. When a beta user can name a result with a number, write it up as your first case studysoon.

Subject: the [product] beta ends on [date]Hi [first name],Thank you for the last 4 weeks. [One line: the thing they reported that you fixed.]The beta ends on [date]. If you want to keep using [product], it's [founding price] for [how long], instead of [normal price]. That price is only for beta users.Here's the link to keep it: [checkout link]Not sure? Reply, or grab 10 minutes: [booking link]. And if it's not for you, I'd love one line on why.[Your name]

Then decide what comes next:

• Some paid, and 40% or more said "very disappointed": open it up. Plan your launch and start working towards your first 100 users. If a launch brings nothing, work out why a launch gets zero signups.

• Under 40%: look at who said "very disappointed". What kind of team are they? Narrow who your SaaS is for to them, and run the next beta group from step 3 with only that kind of team.

• People used it every week, but nobody paid: the product works, but the price or the offer does not. Ask each one why, then work through why no one is buying.

• Few people used it after the set-up call: the problem is not painful enough, or you invited the wrong people. Go back to checking that people want it.

• Tool: Tally or Google Forms for the question, your normal checkout for payment, and your email.

• Time: 2 hours to send the question and the asks, then the calls people book.

• You will have: a list of who paid, who did not and why, and your first quotes and introductions.

• It worked if: every active beta user got a personal ask, and at least 1 in 5 of them paid.

• Common mistake: making the beta longer because you are not ready to ask, or giving everyone free access forever. Both teach you nothing about whether people will pay.

Where Scout7 helps#

Scout7 speeds up two of the seven steps: 1 and 4.

Step 1. Scout7's audience research reads public social conversations in your category and builds audience segments with pain points and quotes in buyers' own words. That gives you the words for "who it is for" and the problem in your beta deal and page. It does not replace the set-up calls in step 5, where you watch real people.

Step 4. Join Conversations searches social platforms for live discussions about your problem, groups them by the kind of reply that fits, and drafts a reply in your voice. You read each thread yourself and approve or rewrite every reply. Nothing is posted without your approval.

Your beta users checklist for the next 4 weeks

0 of 17 done

Work through this list with an AI assistant

It drafts the work and keeps track of what is done.

Do this with ChatGPT(opens in a new tab)Do this with Claude(opens in a new tab)

Step 1 · Write a 4-week beta deal

• Write your beta deal on one page, with an end date and a founding price.

Step 2 · Make a beta page with a 4-question form

• Publish a beta page with an apply button and a 4-question application form.
• Every dayReply to every application within 24 hours.

Step 3 · Send 100 personal beta invites a day

• List people you know who have the problem and people who posted about it in the last 30 days.
• Every daySend 100 personal beta invites.
• Every dayAdd 100 new names who fit to your list.
• Every dayFollow up with everyone who has not replied, up to twice, 3 days apart.

Step 4 · Answer 20 questions a day

• Pick 5 places where your buyers ask for help, read their rules, and post your beta call once where it is allowed.
• Every dayAnswer 20 questions across your 5 places without selling.

Step 5 · Set up every beta user on a 20-minute call

• Create a booking page with 20-minute slots.
• Every dayHold every set-up call, let the person do the main job on real work, and write down where they stop.

Step 6 · Check quiet beta users and count every Sunday

• Every dayMessage every beta user who has not used it in 7 days.
• Every SundaySend each beta user the 3 Sunday questions.
• Every SundayCount who used it this week, and pick the one problem to fix.

Step 7 · End the beta and ask everyone to pay

• Send the "How would you feel if you could no longer use it?" question.
• Ask every active beta user to pay the founding price.
• Decide what comes next using the four rules in step 7.

Copy listDownloadReset