It is Sunday night. The app works on your laptop. You vibe-coded it with your coding agent in a few days, you have a list of people who said they would try it, and the invitation is sitting in a draft message.
Do not send it yet. Not because the app is not good enough, but because you cannot say what you want to know by the end of the beta that you do not know now. Without that, a beta is just a launch with a smaller audience and a worse feedback channel.
This guide gives you a seven-line checklist to complete before you invite anyone. Each line ends in go or fix first, and anything short of go is fix first. When all seven say go, send the invitations. When any says fix first, fix it, check that line again, and carry on down the list. It stops you spending your first users on problems you could have found alone.
A private beta is a learning step, not a soft launch
The group is small on purpose, so that you can learn from every person in it. A private beta means inviting a limited number of people to use your service so you can get feedback and make improvements. A wider public beta comes after, once you are confident you can run the service at scale.1
Three rules follow:
- Decide what you want to learn before you invite anyone. Otherwise you collect whatever lands in your inbox.
- Tell invitees it is a beta. They are helping you learn, not receiving a finished product.
- Agree in advance what result means continue, fix, or stop. Otherwise you will read any result as encouragement.
Do not spend your invitees on things you can find yourself. Save your first users for what only they can show you: whether they can do the job with your app, and whether they want to.
What this checklist does not cover
Not covered by this checklist
Security, privacy and data protection, payments, and legal terms. Get a qualified technical or security review, and follow your organisation's own rules, before you invite anyone. Talking to users does not certify any of these, and seven lines marked go say nothing about them.
The seven lines
1. What you need to learn
Write what you need to learn as questions. Broad, open questions that start with who, what, when, where or why help more than narrow ones, and they are things you need to find out, not questions you will read aloud to users.2 Then attach a decision to each one. Before any research, know what you need to learn now to make an informed decision about what to do next.3
Keep it to three at most, so each one gets proper attention. Unsure which study fits a question? See choosing which research study to run.
- Go when: you have one to three written questions, each opens with who, what, when, where or why, and each names the decision it feeds.
- Fix first if: a question is "will they like it?" or "does it work?", you have more than three questions, or you cannot say what you would change after hearing the answer.
2. The core task
Pick the one thing a first user must be able to do without you. Write it from their side, in one sentence: "Photograph a delivery note and see what differs from my order", not "use the upload feature". Government service guidance asks that people succeed first time, with the minimum of help.4
Then prove it once, before you invite anyone. Give one person who did not build the app the task, and watch them try it. In moderated usability testing you watch participants try to complete specific tasks using the service.5 Stay quiet while they try. You are only checking that the front door opens.
- Go when: one person who did not build it finished the core task on a fresh account, with realistic data, while you watched in silence.
- Fix first if: they did not finish, or finished only because you explained, pointed or fixed something live, or you have only ever tried it on your own account.
3. Failures people can understand
Expect something to break in week one. Make sure that when it does, the person knows what happened and what to do next. Error-message guidance is blunt: merely stating the problem is not enough, so offer some potential remedies.6 "Something went wrong" does neither: it names no problem and offers no remedy.
Break the app on purpose and read what the person would see:
- An empty form or missing file.
- The wrong type of file.
- A lost connection halfway through the task.
- A page refresh in the middle of the task.
- An expired login.
- Go when: each of the five either shows a message in plain words saying what happened and what to do next, with no code or technical term, or recovers without losing the person's work.
- Fix first if: any of them gives a blank screen, a technical message, a message that names no problem, or a dead end.
4. How people reach you
Beta testing includes running the whole service with real users, including the support options.7 Make telling you easier than hunting for your email address.
Settle four things: where the contact is inside the app (a visible "Tell us" link on every screen), who reads it (a named person), how fast you answer (a promise you can keep, such as the end of the next working day), and what happens when that person is away (tell invitees the dates up front, or name cover).
- Go when: all four are written down and the contact link is on every screen.
- Fix first if: the only route is your personal inbox, or nobody is named as the person who answers.
5. What you will collect
Decide now what you will watch, what you will ask, and when.
Watch. Have the app record, for each person, whether they started the core task, finished it, and where they stopped. Read the support messages as a set, not one by one, and use them with the records to see who finished the core task without messaging you: analysing support tickets is a way to identify the problems users have with your service.7
Ask. Send a short hello on day one. Check in at the end of week one with a few short questions, written so that the answers feed your line 1 questions. Those are what you need to learn, not what you read out. Then book a short interview with every person after week two. Interviews give you a deeper understanding of the problems users tell you about.8 Ask people to talk you through the last time they used the app for real; our guide to questions that move past surface answers shows how.
Keep. Pick one place for notes and one weekly time to read them.
- Go when: you can name what the records will show, the check-in and interview dates are set in your calendar for each person, to confirm when they accept, and you know where notes live and when you read them.
- Fix first if: your plan is "I'll see how it goes", or you could not tell from your records and support messages who finished the core task without messaging you.
6. Who you invite
Choose people for what they can show you, not for how confident they are. Write one line per person: why them, and what they can show you that nobody else on the list can. Include someone who does the job a different way today, and someone who is not sure they need your app. Do not fill the list with friends; they will be kind. Keep the group small enough that you can talk to every one of them.
Then write the invitation, and make it read like a beta. Adapt this message:
Hi [name]. I'd like you to try an early version of [app]. It is a beta: it does [the core task], but some things will be rough and some will break. I'm asking you to use it for [the core task] on a real [job] over the next two weeks, to answer a few short questions after the first week, and to give me 30 minutes to talk after the second. I can see how the app is used, so I know where people get stuck. If anything goes wrong or confuses you, use the "Tell us" link or message me at [contact]. I reply by [time promise], and I'm away on [dates]. Please don't rely on it for anything you cannot do another way.
Say plainly what you will record, and follow your organisation's consent and privacy rules about it.
- Go when: every invitee has a written reason, the group includes someone who works differently and someone unconvinced, and the invitation says it is a beta, what you ask of them, and how to reach you.
- Fix first if: the list is only friends and fans, or the invitation reads like a launch announcement.
7. Exit criteria
Decide, before you see any data, what result means continue, fix or stop. Government guidance puts public beta after you have improved the service and are confident you can run it at scale.1 So "continue" here means a wider group or the next learning question with the core task unchanged, never "launch". "Fix" means changing the steps where people got stuck and repeating the round.
Write the rule like this:
-
Count people, not impressions: "four of six", not "most".
-
One criterion on whether they can do it (they finish the core task in week one without messaging you; count it from your records and support messages) and one on whether it matters to them (they used it for a real job in week two).
-
Check stop first, then continue. Stop means you pause invitations and revisit whether the core task is worth building. Fix is everything else.
-
Add a review date. Make the decision on that date, with the criteria you wrote.
-
Go when: stop and continue are each written as counts of people, fix is everything else, and you have a review date.
-
Fix first if: your criterion is "see how it goes" or "if people seem positive".
The checklist to copy
Copy this into a document. Keep the names of the lines, because the example below uses them.
PRIVATE BETA READINESS CHECKLIST: [app name], [date]
1. WHAT YOU NEED TO LEARN (one to three questions)
Q1: [who / what / when / where / why ...]
Decision it feeds: [...]
Q2: [...]
Decision it feeds: [...]
Q3: [...]
Decision it feeds: [...]
Result: GO / FIX FIRST Fix: [...]
2. THE CORE TASK
In one sentence, from the user's side: [...]
Tester who did not build it: [name, date]
Watched in silence? y/n Finished? y/n
Fresh account? y/n Realistic data? y/n
Result: GO / FIX FIRST Fix: [...]
3. FAILURES PEOPLE CAN UNDERSTAND
Each: says what + what next, or recovers, work kept
Empty form or missing file: y/n
Wrong file type: y/n
Lost connection mid-task: y/n
Refresh mid-task: y/n
Expired login: y/n
Result: GO / FIX FIRST Fix: [...]
4. HOW PEOPLE REACH YOU
Contact inside the app: [...] Who answers: [...]
Reply within: [...] Cover when away: [...]
Result: GO / FIX FIRST Fix: [...]
5. WHAT YOU WILL COLLECT
Watch (records): [...]
Ask: day one [...]; week-one check-in [...]; interviews [...]
Notes live in: [...] Read weekly on: [...]
Result: GO / FIX FIRST Fix: [...]
6. WHO YOU INVITE
Name / why them / what they can show you: [one line each]
Includes someone who works differently? y/n
Includes someone unconvinced? y/n
Invitation says: beta, what you ask, how to reach you? y/n
Result: GO / FIX FIRST Fix: [...]
7. EXIT CRITERIA (written before the first invitation)
Stop if: [counts of people]
Continue if: [counts of people]
Fix if: anything else; fix the steps where people stopped.
Review date: [...]
Result: GO / FIX FIRST Fix: [...]
INVITE WHEN ALL SEVEN SAY GO. ANYTHING ELSE IS FIX FIRST.
An invented example
Here is an invented example to show the method.
Dana runs the ordering at her own café. She built a small web app with her coding agent over a weekend. You photograph a supplier's delivery note and the app lists what differs from what you ordered. She wants to invite six café owners and managers, chosen for how they handle deliveries, not because they would be kind about it. Four she knows from her old job. Two she has never met; she found them through a local trade group.
Working down the list, four lines first came out fix first and three came out go.
| Line | First pass | What she found and changed |
|---|---|---|
| 1. What you need to learn | Fix first | Her question was "will they like it?". She replaced it with three. Q1: what do people do with the photo step on a real delivery, and where do they stop? Decision: which step to simplify first. Q2: what do they do when the app flags a difference that is not real? Decision: whether to add a manual override. Q3: why would someone go back to paper or a spreadsheet? Decision: whether to keep building. |
| 2. The core task | Fix first | Task: "Photograph a delivery note and see what differs from my order." Her sister had never seen the app and got stuck, because today's order had to be entered first and Dana had always entered it herself. She moved "Add today's order" to the first screen, then watched a second person who had not built it finish, in silence, on a fresh account with realistic data. |
| 3. Failures people can understand | Fix first | She broke the app the five ways on the list. Two of the five, the wrong type of file and a lost connection mid-upload, gave a blank screen. Both now say what happened and what to do next. |
| 4. How people reach you | Go | A "Tell Dana" link on every screen. Dana reads it and replies by the end of the next working day, and her away dates go in the invitation. |
| 5. What you will collect | Go | The app records who started and finished the core task and where they stopped. A day-one hello, a week-one check-in with short questions written from her three research questions, and a 30-minute interview after week two have dates set in her calendar for all six, to confirm when each accepts. Notes live in one shared document that she reads every Friday. |
| 6. Who you invite | Go | Six people: two who check deliveries on paper, two who use a spreadsheet, one who doubts she needs it, and one whose staff take deliveries. Each has a one-line reason. The invitation says it is a beta, what she asks of them, and how to reach her. |
| 7. Exit criteria | Fix first | Her draft said "see how it goes". She replaced it with the rule below. |
Her exit criteria, written before any invitation:
- Stop if one or fewer of the six finish the core task without messaging her in week one, or if none of the six uses the app on a real delivery in week two.
- Continue if four or more finish the core task without messaging her in week one and three or more use it on a real delivery in week two, confirmed in the interviews.
- Fix in every other case: name the steps where people stopped, fix them, and run a second round.
She set a review date at the end of the interviews. After her changes all seven lines said go, and she sent six invitations. Outside the checklist, she had someone qualified review security and how the app handles data before any invitation went out. The checklist does not do that for you.
What this will not tell you
This checklist tells you whether your first users can teach you something. It does not tell you the app is safe, lawful or ready for everyone. A handful of invited people can show you what goes wrong and why. They cannot tell you how many of your eventual users will behave the same way, and because they agreed to take part, they are not a random sample of those users. Read every count in your exit rule as a count of people you invited. The checklist is a working tool, not a validated scoring system.
Your next step
Open a blank copy of the checklist and fill in line 1 before you touch the app again. If you cannot write even one question with a decision attached to it, you are not ready to invite anyone, and it is better to find that out on Sunday night than in week two. When all seven lines say go, send the invitations.
