Before you launch or pay for traffic
Pre launch QA: the sign-up path a new user takes
Your last pass ran on a session that already knows you. A new user meets the public address with nothing saved, and a QA run from a fresh browser shows what they meet.
What is a pre launch QA pass?
A pre launch QA pass runs the sign-up and checkout paths one more time on the build you are about to release, from a browser that has never seen the site. It is where production settings, cookies and redirects get checked, because they differ from staging in ways a signed-in test never touches. The faults that reach launch tend to be environment faults, such as a cookie domain or a live key, not logic faults. A simulated test sends new visitors through the public address and shows the step where each one stopped, with a screenshot.
What this looks like in a report
“I signed up and the page said check your inbox. The link in the email opens a login page, and it says my account does not exist. I will just use the other scheduler the clinic already has.”
The fix. Build the confirmation link from the live domain setting, not the staging one, and check it from a logged out browser before release. Show the login page a message that says the link has expired, with a button to send a new one.
An illustration. Run a test to see your own.See a real sample report
Your last QA run uses a session you already have
A QA run by the person who built the product starts logged in, with a cookie and a saved address already in place. A session cookie set for one host, such as the www address, is not sent to the bare domain unless the cookie's domain covers both, so a visitor who signs up on one and lands on the other is sent back to the login form with no error. Your build may also read a payment key or a redirect address that was never changed for the public domain. A run from a new visitor is where both show up, because nothing is saved for them yet.
- The session survives a move from the www address to the bare domain, and from the bare domain back.
- Production reads the live payment key and the public redirect address, not the staging values.
- The confirmation link in the email opens the live domain, from a browser that is logged out.
- A wrong password, a blank required field and a taken address each show a message beside the field.
- A new account reaches a first screen that says what to do, not an empty page.
How it works
- 01
Start from a browser that has never visited the site
Use a private window or a fresh browser profile, and open the public address the way a visitor would. Do not start from a bookmark that carries an old session.
- 02
Sign up, then open every email it sends
Create an account with an address the simulated visitor controls, and open the confirmation link in the same browser. A link that opens another host or an expired page is a launch fault.
- 03
Walk the first screen, then the errors
After sign-up, type one wrong password, leave one required field blank and try an address that already has an account. Each message should sit beside its field, and none should show a raw code.
- 04
Run the same path again after each fix
Repeat the run on the new build with new visitors. A fix that clears one login error can still break the email link, and the second run is where that shows.
Cookies set on www that stop at the bare domain
Start with the host name. Load the bare domain and the www address in the same browser, sign in on one, then load the other. If you are signed in on one and asked to sign in again on the other, the session cookie belongs to a host you did not open. None of this is a logic bug, so unit tests pass while a new visitor meets a login form that never accepts them. Set the cookie domain to the host you ship, then repeat the run from a fresh browser, since a browser holding the old cookie hides the fault again.
Production settings that staging never exercised
Staging usually runs test payment keys, a sandbox mailer and a database full of fake rows. Production replaces each of those, and the replacement is where sign-up fails quietly. A confirmation email may send from an address the mail provider has not verified. A redirect address may still list the staging domain. A feature flag may be off in production and on in your account. List each value the sign-up path reads, check it against the build that will ship, and run a new visitor against that build to find the step that waits for a missing value.
Errors a stranger triggers in the first minute
A signed-in tester rarely types a wrong password, leaves a required field blank, or enters an address that already exists. Check that each message sits beside the field it describes, names the problem in plain words, and leaves the other values the visitor typed. A form that clears every field after one error is an easy launch fault to ship, and it makes the visitor type the whole sign-up again.
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 config change after launch can cut the sign-up path again
Launch is not the last release. Each config change, cookie domain edit or new mail provider can cut the sign-up path again, and the fault may show only for visitors who arrive on the other host. Run the same new visitors through the path after every release, and read the step where each one stopped. Check each preview deploy before its link goes out.
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
Do I need a pre launch QA pass if I have automated tests?
Yes, though the tests still help. Automated tests usually run against one host, with one set of settings and often a signed-in fixture. A run from a fresh browser on the public address covers the host, cookie and redirect settings those tests skip.
Which browsers should the QA pass cover?
Cover the browsers your visitors use, at least one desktop browser and one phone browser. A sign-up form can behave differently on a phone keyboard, and autofill can fill a field with a value the form rejects. A pass on one browser cannot show those faults.
Can the test confirm that my payments work?
No. Visitors cannot pay with a real card, so checkout goes up to the payment step and stops. It cannot show a declined card or a receipt. Run one real payment with a card you own, refund it, and read the receipt it sends.
Does passing the test mean the build is ready to launch?
No. It shows that a new visitor can reach the first screen on the public address with the current settings. It cannot tell you whether the build is secure, fast under load or covered by the right legal pages. Those need their own review, and the test does not replace them.
What does a blocked visitor mean in a QA run?
A visitor stopped by a CAPTCHA or bot protection is marked as blocked by the site. The sign-up did not fail. The protection stopped the visitor, so decide whether real new accounts should meet it, then run again from the same address.
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.