To decide who gets into early access, write down the one job early access is for, score every signup 0 to 2 on four traits (ICP fit, problem urgency, willingness to talk and use-case clarity), and invite the top scorers in batches of 8 to 15 that you can support yourself. Everyone else gets an honest "not yet" with a clear point when you'll look again, so a small first group doesn't cost you the rest of the list.
Last updated: Nov 10, 2026
This is for indie founders who already have signups and need a fair way to choose who gets a seat now. It's the gate between "interested" and "in the product", not the job of building the list. If you're still growing the list itself, start with how to build a waitlist that converts when you launch. Research figures below link to their sources (read 10 November 2026); the worked example is illustrative.
Why shouldn't you let everyone into early access?
Because early access isn't a prize. It's a way to learn, and every seat costs you support time. Let everyone in and three things happen fast:
The signal gets diluted. You hear "love the idea" from people who never finish onboarding, and "missing feature X" from people outside your ICP (ideal customer profile). Both feel like data. Neither should steer the roadmap equally.
Support goes to the wrong people. A confused user who was never a fit takes the same hour as a sharp one, and that hour comes out of your product time.
You set the wrong expectations. Casual invitees treat early access like a free-forever tier, and when you start charging, the loudest complaints come from people who were never going to stay.
Being selective protects the feedback you're trying to get. It's the same reason you keep an early-access list warm until launch day with deliberate emails: attention is scarce, so spend it on people who can teach you something.
What job is your early access for?
Before you score anyone, finish this sentence: Early access exists so that ________. Fill it with a job, not a feeling. Sentences that work:
"…so I can watch five ICP users complete the core workflow twice a week and see where they stall."
"…so I can test whether people who already pay for a painful workaround will pay for this."
"…so I can stress-test onboarding with non-technical buyers in my niche."
Sentences that fail: "so the waitlist number looks big", "so my friends feel included", "so influencers maybe post about it".
That sentence is your filter. If someone can't help with that job, they wait, even if they're nice, well known or first on the form. Also write down who it's not for this month (say, "people who want a free version of a mature tool"), so you don't argue with yourself later.
If you need three to five companies to shape a B2B product with you over months, that's a different ask: see how to run a design partner program before your product exists. Early access is lighter. People use the product and tell you what broke.
How do you score early-access applicants?
You don't need a CRM. A sheet with one row per person and five columns is enough. Score each person 0 to 2 on four traits, add them up, and invite from the top.
Trait | 0 | 1 | 2 |
|---|---|---|---|
ICP fit | Wrong role, industry, or company size | Adjacent; might stretch into ICP | Matches your stated ICP exactly |
Problem urgency | Curious / "might try later" | Has the problem monthly | Has the problem weekly; already paying time or money for a workaround |
Willingness to talk | Email-only, no replies historically | Will answer async questions | Agreed to a 15-min call or already replied thoughtfully |
Use-case clarity | Vague ("looks cool") | One concrete job mentioned | Specific workflow + success definition ("I need X every Friday for clients") |
The total runs from 0 to 8. Cut lines that work for a solo founder:
6–8: invite in the next batch.
4–5: hold on the waitlist and ask one clarifying question.
0–3: send a polite "not yet" with a way back in.
Which signup questions give you the answers?
Besides email, ask two short open questions: "What are you trying to get done?" and "How are you handling it today?" An optional third, "Would you hop on a 15-minute call if invited?", sorts the curious from the people who'll actually help.
What if someone scores high but won't talk?
Invite them anyway, but put them in a "usage-only" lane with lighter expectations. Not every early user has to be a research partner. Some should just use the product while you watch what they do. The ones who will talk are worth the most when you want to get on a call with your first users instead of guessing from dashboards.
How many people should be in each early-access batch?
Fewer than you think. Don't drip one invite a day, and don't send the whole list on Monday. Batches give you groups you can compare.
First batch: 8 to 15 people. Enough to see patterns, few enough that you can reply to each one within a day.
Later batches: 10 to 25, and only after you've fixed the top two problems from the batch before.
The research on small groups backs this up. In Jakob Nielsen's "Why You Only Need to Test with 5 Users", a single test user uncovers about 31% of a design's usability problems on average, five users find about 85%, and after the fifth you mostly see the same problems again. He recommends three rounds of five with fixes in between rather than one round of fifteen, and three or four people from each clearly different user group.
Early access isn't a lab test, and some invitees won't show up. But the lesson carries over: a batch of 8 to 15 gives you roughly five active people from one or two user types, which is where most of the learning is. Inviting 60 on day one mostly gets you the same complaints, many times over.
How far apart should batches be?
About a week at the start. Use it to watch who finishes setup, fix the obvious bugs and adjust the rubric if the wrong people keep scoring high (usually a form-question problem). In each batch, add one or two "stretch" users who are adjacent but unusually articulate. Stretch users are seasoning, not the meal.
What does this look like with a real list?
An illustrative example, not a real company: a solo founder is building "Chaseline" (a made-up name), a tool that chases unpaid invoices for freelance designers. The waitlist has 140 signups.
Job statement: "Early access exists so I can watch freelance designers send their first automated reminder and see whether a client actually pays."
Capacity: she has about six hours a week for support and calls. At roughly 30 minutes per active user per week, that's 12 people. Batch one is 12 invites.
Scoring: 140 rows took about two hours. 21 people scored 6 to 8, 38 scored 4 to 5, and 81 scored 0 to 3, mostly signups that left the open questions blank.
Batch one: 10 of the 21 top scorers (the ones who said they chase invoices weekly), plus 2 stretch users (a copywriter and a video editor with the same problem).
Everyone else, same day: the other 11 top scorers hear "batch two, about a week out", the 38 middle scorers get one clarifying question, and the 81 low scorers get a "not yet" naming the next milestone.
To compare batches later, she tags the link in each invite email with the same campaign and a different utm_content value (batch-1, batch-2) using EarlyHunt's free UTM link builder, so her analytics show which batch actually came back. After week one, 9 of the 12 had logged in and 6 had sent a real reminder. The step where three people stalled was connecting their invoicing tool, so that's the fix before batch two. These numbers are illustrative; the method is the point.
How do you know whether a batch worked?
Track three things per batch: how many accepted, how many reached the first useful moment, and how many came back later without a nudge. Then ask one more question.
In Rahul Vohra's First Round Review piece on how Superhuman found product-market fit, the team asked users "How would you feel if you could no longer use Superhuman?" Growth expert Sean Ellis had found, after benchmarking nearly a hundred startups, that companies where over 40% answered "very disappointed" usually had strong traction. Superhuman started at 22%. Focusing on the kinds of users who were already "very disappointed" moved it to 33%, and three quarters of product work took it to 58%. They only surveyed people who'd used the product at least twice in the last two weeks, and Vohra says results start to be directionally correct at around 40 responses.
For early access, the "very disappointed" group shows who belongs at the top of your rubric next time. One batch of 12 won't give you 40 answers, so pool responses across batches and read them as a direction, not a verdict. For the full method on a small user base, see how to run a product-market fit survey with under 100 users.
What should the early-access invite email say?
Your invite is the deal. Say what early access is, what you need and what "rough" means before they click.
Invite email sketch (edit the brackets):
Subject: You're in: early access to [Product] (small batch)
Hey [Name],
You're in the next early-access batch for [Product]. I picked you because [one specific reason from their form answer].
What this is: a small group (about [N] people) shaping the core workflow before a wider launch. Edges will be rough. Replies come straight to me.
What I need from you in the first 10 days:
Try to complete [core job] at least twice
Reply with what blocked you (screenshots welcome)
Optional: a 15-minute call if something feels important
Login: [link]. If timing is bad this month, just say so and I'll move you to the next batch, no hard feelings.
[You]
The specific reason proves you read their answer. The easy way out keeps trust with people who should wait.
How do you say "not yet" without losing people?
An honest, temporary "no" is fine. Silence is what burns a list.
"Not yet" reply sketch:
Subject: Early access update for [Product]
Hey [Name],
Thanks for signing up. This round of early access is a small batch focused on [ICP / job]. You're not in that slice yet, so I'm keeping you on the waitlist rather than giving you a half-baked seat.
What happens next: I'll email when we open the next batch or when [specific milestone, e.g. "team invites ship"]. If your use case is [adjacent thing], reply and tell me. I'll note it for a later group.
Thanks for being early.
[You]
Don't invent fake scarcity or say "we'll see" without a way back in. For people in the middle band, send one question instead of a no: "Quick check: when you said [quote], did you mean [A] or [B]?" The reply often moves them up or makes the wait obvious.
How do you keep the selection fair week to week?
Without a routine, you drift into inviting whoever emailed you last. Block 45 minutes every week:
Score new signups, and re-score anyone who replied with more detail.
Pull the top N for the next batch, checked against your job statement.
Review the last batch: who got set up, who vanished, who gave useful feedback. Adjust the weights if needed.
Send invites and "not yets" the same day. Don't leave people hanging for three weeks.
Write down one pattern, like "agency owners got set up; students bounced". It feeds your positioning later.
If you skip the review two weeks running, pause new invites.
What are the most common early-access mistakes?
Friends only. Friends are kind and often outside your ICP. Cap them at one or two seats per batch, scored like everyone else.
Influencers only. A big account that won't use the product is marketing, not early access. Run a separate creator preview if you want reach.
Everyone who signs up. A waitlist is a queue, not a promise of instant access. An unfiltered public beta is a later stage.
Breaking the promise on your waitlist page. If the page said "first come, first served" or "share to move up", either honour it or change the page before you hand-pick. People notice.
Scoring vibes instead of answers. "They seem cool" isn't a trait. If the form doesn't collect use case and urgency, fix the form first.
Inviting faster than you can support. Empty Discord channels and unanswered bug reports teach people to stop engaging. Shrink the batch until you reply to anything blocking within a day.
What happens when early access ends?
When a batch gets through setup without your help, it's time to open up. Plan two things first.
First, the people already inside. Tell them early what changes, what it'll cost and what they keep for being early. We cover timing, opt-outs and wording in how to convert closed beta users into paying customers without burning trust.
Second, the people who haven't heard of you yet. Your notes on who got set up and what they said in their own words are the best material for public pages. If you want an outside write-up of that reasoning, Piece Press publishes longer explainers that walk a reader through one decision, such as who your product is the right call for and who it isn't.
After the public launch, most new people find you through pages about your product on other sites. One option is Posting Dude, a done-for-you monthly editorial backlink service run by the same team as EarlyHunt: Launch is $249/mo for one project and Studio is $399/mo for up to three, with 10 editorial articles per project each month across a 10-site network. It's a publishing service, not a promise of rankings or traffic, so judge it like any other channel.
What's a one-week plan to get started?
If you have a list and no system yet, run this:
Day 1: write the job statement and exclusions; tighten two signup questions.
Day 2: score the list 0 to 2 per trait and sort it.
Day 3: invite batch one (8 to 15) and send "not yet" notes to the bottom third.
Days 4–7: watch setup, reply fast, fix the top problem.
Next Monday: run the weekly review; open batch two only if batch one taught you something.
FAQ
Should early access be first come, first served?
Only if that's what you promised. Signup order rewards speed, not fit. A common middle ground is to invite mostly by score, keep a few seats for the earliest signups, and say on the waitlist page how it works.
Should early-access users pay?
If the job is testing whether people will pay, ask for payment or a clear commitment early. If it's finding where onboarding breaks, free is fine, as long as you say upfront what happens to pricing later.
How long should early access last?
Until a batch reaches the first useful moment without your help. For most small products that's a few batches over several weeks. A "forever beta" usually means the scope or selection needs fixing.
Summary: choose on purpose
Early access works when every seat is filled for a job: learning, proof that people get set up, or an honest pricing signal. Open invites feel kind and cost you for months. A simple rubric, small batches, clear invites and respectful "not yets" keep trust while you learn from the right people.
Pick who gets in. Tell everyone else when you'll look again. Then build for the people who actually showed up to do the job.