A beta tester signup page that finds testers, not just emails
A beta needs a few dozen people who match your target user, have the right device and will actually report back. A bare email box gives you hundreds of curious strangers instead. Ask a handful of screening questions, send every application to a table you can sort, and invite in small waves.
A list is not a test group
A waitlist page measures interest: the more sign-ups the better. A beta has a different goal. You want coverage of the setups that could break your product and people whose feedback will change what you build. Twenty engaged testers who match your user beat five hundred who signed up on a whim and never open the build.
That changes the page. Instead of one field and a big button, it explains what testing involves and asks enough to choose well. The extra friction is useful: people who won't spend two minutes on an application rarely spend two weeks testing.
What the page should tell applicants
- What they'll test, in one paragraph and a screenshot.
- What you'll ask of them: "use it for real for two weeks and answer a five-minute survey at the end".
- When: the start date, how long the beta runs and when you'll tell people whether they're in.
- What they get: early access, a say in the roadmap, sometimes a discount at launch. Keep promises you can keep.
- What could go wrong: data may be reset, things will break. Testers who expect bugs report them; testers who don't, leave.
- How you'll use their answers, and that you won't add them to marketing email unless they ask.
Screening questions that matter
| Question | Answer type | What you'll do with it |
|---|---|---|
| Name and email | Text | Invite and follow up |
| Which device and operating system will you test on? | Short text or a list | Spread testers across setups |
| What would you use this for? | A sentence or two | Match your target use cases |
| What do you use for this today? | Short text | Find people switching from a competitor |
| How many hours could you give it in the next two weeks? | A number | Drop anyone who can't spare an hour |
| Have you tested a product before? | Yes or no | Mix experienced and first-time testers |
| Anything we should know? | Optional text | Accessibility needs, team size, odd setups |
Seven questions is about the ceiling. Leave out anything you'd ask once someone is in, such as feedback preferences or time zone.
Sorting applications in Airtable
Send each application to an Airtable base and add your own columns: status (new, invited, active, dropped), wave, and a notes field. Filter by device to see whether you've covered each setup, then invite in waves of ten or twenty. Wave one finds the obvious bugs; later waves find the rarer ones. If someone goes quiet after a week, move them to dropped and invite the next applicant who matches. The recruit beta testers workflow covers invitations and follow-up.
How Anticode builds it
Describe the product and the testers you want, for example "a beta signup page for our iPad sketching app, with what testers do, the timeline and an application form asking about device, use and hours available". Anticode's built-in forms have fixed fields: name, email and a message for contact, or just an email for the newsletter form. An application with your own questions is a custom form tied to a site function, with up to 30 plain-text fields; the function runs on the server when the form is sent, and its heading and message appear on the thank-you page, so you can say exactly what happens next. Ask for the questions you want and check the preview to confirm they're there.
Submissions are saved in your dashboard, sealed at rest, and can be emailed to you. Add the Airtable connector to the site and each one is sent to your base; it's sent once without retries, so compare counts with the dashboard now and then. Slack, Notion or a Google Sheet work the same way if you'd rather triage there.
Limits
- No distribution of the build. Send testers TestFlight, Play testing or download links yourself.
- No feedback collection inside the product. Use a survey tool or your own form after each wave.
- No file uploads, so applicants can't attach screenshots. Ask for a link if you need one.
- No tester accounts or private beta pages. Published pages are public, so don't put the build link on the page.
Questions people ask
How many beta testers do I need?
Enough to cover each device and use case you care about, a few times over. For a small product that's often 20 to 50 active testers across two or three waves.
Should I accept everyone who applies?
No. Accept the ones who match your target users and setups, and keep the rest on the list for launch.
Can rejected applicants still get launch news?
Yes, if they agreed to it. Add a separate newsletter sign-up so you're not emailing people who only applied to test.