Before you launch or pay for traffic
Pre launch waitlist: check the join step
The form says you are on the list. Whether you are depends on three steps the page never shows you: the email rule, the save and the confirmation.
What can go wrong on a pre launch waitlist form?
A pre launch waitlist form fails in three places: the address check rejects a valid email, the success message appears before the record is saved, or the confirmation link opens a dead page. Each failure shows the visitor a message that looks like success or a vague error, so the owner may never hear about it. Read the form as three separate steps, the input, the save and the email, and test each one. A simulated test joins the list from a public address as a new visitor, and shows which of the three steps stopped each one, with a screenshot.
What this looks like in a report
“I use a plus address to keep sign-up mail apart. The form says invalid email, but that address works everywhere else. Either the form is broken or they do not want me. I will use my normal address.”
The fix. Accept the email forms your mail provider accepts, including plus signs, and show an error beside the field only when the at sign or the domain is missing. After a join, show the confirmation on the page and send the email at the same moment.
An illustration. Run a test to see your own.See a real sample report
The join message can appear before anyone is on the list
A waitlist asks for one thing, an email address, and gives back one thing, a feeling of having joined. The fault usually sits in the gap between those. The page can show a success message before the record is saved, or save the record and send a confirmation to an address the form rejected a second earlier. A check written for common addresses may refuse a plus sign, a capital letter or a newer domain ending. The visitor then retypes the address, and each retype is another chance to fail. Check the saved record, the sent email and the on-screen message as three separate things.
- Addresses with a plus sign, a capital letter or a newer domain ending are accepted.
- The success message appears only after the record is saved, not before the request returns.
- Joining again with the same address shows a clear message, not a blank form.
- The confirmation email reaches the main inbox, and its link opens a page that says the visitor is confirmed.
- An error for a real mistake, such as a missing domain, sits beside the field that caused it.
Address checks that reject people's real addresses
Plus addressing, where a person adds a tag before the at sign, is common among people who keep sign-up email apart. A rule that allows only lowercase letters, numbers, dots and hyphens before the at sign rejects plus signs and capitals in the name part. Domains are not case sensitive, so a capital letter after the at sign is still the same address. A short list of allowed endings rejects a work address on a newer domain. Test three addresses in the join form: one with a plus sign, one with capital letters, and one on a newer domain ending. Each should join, or show a message beside the field that names the problem.
A success message that arrives before the save
A success message should follow a saved record, and the order is easy to get wrong. If the page shows that you are on the list and the request then fails, the visitor believes they joined and the list does not have them. Test it. After joining, refresh the page and see whether the form offers the join again. If it does, the record was not kept, and the save is the first thing to check. The confirmation email is the second signal. If the message promised one and the inbox stays empty, the save or the send failed, and the visitor cannot tell which.
Confirmation links that open a dead page
A double opt-in waitlist emails a link the visitor must open before they count. That link can point at a staging address, an expired token, or a page renamed after the email went out. Open the link from the email in the same browser, then again in a logged out window. The visitor should land on a page that says they are confirmed, and shows their place in line if you show one. A page that says not found, or asks them to join again, loses the people who did the hardest part of the join.
Simulated joins measure the form, not interest
A simulated visitor joins the list because the test asks it to, so a count of simulated joins says nothing about demand. The test cannot tell you how many people on the list will open the launch email, or whether a referral reward would bring more. It can show where the join breaks and whether a visitor who has to join gets a confirmation. Count real joins from your own list, and treat a simulated join as a check on the form, not a measure of interest.
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 new form field or a new email tool can drop joins again
A new field, a new sender address or a moved confirmation page can break a join that worked last week. Run the same visitors through the join after each change, including the plus-sign and capital-letter addresses, and read whether each one was saved and confirmed. A members page behind a login can be reached with a test account given with paid credits, and a preview copy can be checked before the change goes public.
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 a waitlist ask for more than an email?
Each extra field is a step a visitor can fail on. Ask only for what you will use on launch day, and say why beside each one. The test shows whether each field is reachable on a phone and whether an error appears beside it. It cannot tell you whether a visitor would answer the question.
Does a double opt-in step lose people?
It can. A visitor who never opens the email is not on the list, and the test does not predict how many visitors will open it. The test shows whether the confirmation arrives and whether its link works. Measure the opens from your own email tool once real people join.
What if the confirmation never reaches the visitor's inbox?
Visitors have a working inbox, so a confirmation that does not arrive points at your send: the sender setup, the mail provider or a job that failed. Check your mail provider's sending records for that address, since the test cannot see inside your provider. Spam filtering depends on the sender setup too, so check it there.
Can a visitor sign in to see their place on the list?
Only if you offer an account, and visitors cannot sign in with Google or single sign on. If a place page needs a login, the test stops at the login step, and the report shows that step with a screenshot.
Do I need a referral step?
Not for the join to work. A referral step adds another branch to test. Add it after the plain join works from a phone and a laptop, then test the referral link as its own path.
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.