Before you launch or pay for traffic
How to create a waitlist: what happens next
A waitlist page asks people to give an address for something they cannot use yet. The page has to say what happens after they join, or they will assume nothing happened.
How do I create a waitlist page before my product is ready?
Name the product and the one problem it solves, then ask for an email address and say what the person gets when they join. Send a confirmation that names the next step, such as the month you will write again, so the wait has a known end. A simulated visitor joins from the page with a working inbox and shows whether it knows what happens next.
What this looks like in a report
“It says coming soon and asks for my email. I do not know when it opens, or whether joining gets me anything. If I type it and nothing happens, I have lost nothing, but I will not know.”
The fix. Put one date or the next step above the form, such as the month you will write again and what the first email contains. Then join from a phone with a fresh address, confirm the email names the same date, and check what the page says when the same address joins twice.
An illustration. Run a test to see your own.See a real sample report
Joining feels like sending a letter to nobody
A founder who builds a waitlist knows what the product does, so the page feels clear to them. A stranger sees a headline, a form and a promise with no date. They type an address, see a short thank you, and wait for something that was never named. Many stop there, because nothing on the page says the sign-up counted. Others join twice, unsure whether the first try went through. The founder cannot see this from inside, since their own address is already on the list.
- Date: does the page say when, or the next step and when you will write?
- Form: is the address the only required field?
- Thank you: does it name the list and say where to look for the email?
- Repeat join: does a second try with the same address explain itself?
How it works
- 01
Say what joining gets, in one line
Name the product and the single result it gives, such as a booking page for dog walkers. Add what the person gets first, such as early access or a note when it opens. Do not promise anything you cannot deliver on that date.
- 02
Ask for an address and nothing else
A waitlist is a free step, so every extra field gives a stranger a reason to leave. Ask for the email now, and ask about role or company later, once they have a reason to answer.
- 03
Confirm in the inbox and name the next step
Send a confirmation that says their place is saved, what happens next and when you will write again. Check that it arrives in the inbox and that its links open the live site.
- 04
Join twice from a phone to test the repeat
Join from a phone with a fresh address, then join again with the same address. Note whether the page says you are already on the list, or shows an error that makes it look like the sign-up failed.
A launch date changes what a waitlist promises
A page that says coming soon promises nothing, so a visitor cannot judge whether waiting is worth it. If you have a month in mind, write it, and say what could move it, such as a beta round that is still testing. If you have no date, say what you will send and when you will next write. The date on the page and the date in the confirmation email must agree, or a stranger will trust whichever one they saw last.
The second join attempt is where waitlists break
Visitors do try again, usually because the first attempt showed nothing clear. A page that answers a second join with Something went wrong looks like a failure, and the visitor joins a third time. The right message is plain: this address is already on the list, and the confirmation is in your inbox. Check the duplicate case on purpose, since a founder rarely signs up twice from their own browser.
What the thank you page must answer
The thank you page is the only place a stranger learns that their sign-up counted, because a waitlist has no product to show yet. It should name the list they joined, give the month they will hear more, and tell them where to look if the email does not arrive, such as a spam folder. A page that only says thanks leaves the visitor to guess. Read it as someone who comes back to it a week later, looking for the email that never came.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A launch date that slips leaves the waitlist promising the old day
Waitlists stay live for months, and a launch date that moves leaves the page and the confirmation email promising the old day. Each change to the date, the offer or the confirmation needs the same join path run again, so the page and the email tell a stranger the same thing.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Should I show how many people are on the list?
Only if the number is real and you are willing to show it on every visit. A small figure that stalls can work against you. Many founders show nothing and give a clear next step instead, which a stranger can check for themselves.
Do I need referral rewards?
Not for the first test. A referral reward adds a second action to the page, and a visitor has to understand the first one before they can judge the second. Add it after the basic join path works from a phone.
Can a simulated visitor show whether my waitlist is worth building?
No. It does not predict how many people join, how many come back or how many buy when the product opens. It shows whether a stranger understands what joining gets them, can give an address, and sees a clear next step after the join.
What if the waitlist page sits behind a password?
A visitor can reach a page behind a site password only through a protected preview, which needs paid credits. Otherwise the run stops at the password screen and reports that as the step where the visitor stopped. A page on a private network is out of reach for a visitor at all, so check that path from a browser on your own network.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.