How do I test my signup flow before launch?

A signup check you can run today

1. Start where a stranger starts: signed out, in a private window, on the production address rather than staging.
2. Before the form: can someone tell what they get, what it costs and whether a card is needed, without opening the FAQ?
3. The button: does “Sign up” or “Get started” go straight to the form, or through a detour?
4. The form: ask only for what the first session needs. Every field has a visible label, and every error says exactly what to fix.
5. Passwords: are the rules shown before the first attempt, not after the error?
6. Verification: does the email arrive promptly, and does its link land you signed in on the same device?
7. Social sign-in: if you offer Google or another provider, do you end up with the same account as with email?
8. The first signed-in screen: does it tell a new user what to do next?
9. Coming back: log out, log in, mistype the password, reset it.
10. On a phone: do it all again at phone width.

Some of these are also what the persona in Menso's Sign up & log in template watches for: a senior product manager who expects an account to take two minutes, dislikes forms that ask for a phone number or company size first, and trusts validation messages that say exactly what to fix. The template does not test social sign-in, logging out and back in, password reset or phone-width layouts: web runs use a fixed desktop window.

Automate the steps you repeat after every deploy

Playwright's test generator opens your site in a browser, records what you click and type, and writes the test code as you go: run npx playwright codegen with your signup address. The same test runs in Chromium, WebKit and Firefox. For tests that should start signed in, Playwright's authentication guide shows how to log in once in a setup project and save the browser state to a file the other tests reuse. That file holds session cookies, so keep it out of git.

The test also needs to receive the verification email. Tools that do this, by how they work:

• Mailosaur gives you addresses that receive mail with no setup, of the form anything@your-server-id.mailosaur.net. Its Playwright client waits for the message and hands the test the codes and links it found. Plans start at $20 a month billed yearly, with a 14-day trial, and text-message testing is on the Core plan (pricing).
• Mailpit is free and open source. It runs as the SMTP server for your staging app and keeps every message it receives, with a web inbox and a REST API your tests can read. It only sees mail your own app sends to it, so use it on staging.
• testmail.app has a free plan of 100 emails a month, kept for one day. The Essential plan, at $9 a month billed yearly or $12 monthly, includes full API access (pricing).

An automated test tells you the signup still works after a change. It cannot tell you whether a label confuses people.

Security checks from OWASP

• The same reply for every email address. OWASP's Authentication Cheat Sheet gives “A link to activate your account has been emailed to the address provided” as the right signup reply and “This user ID is already in use” as the wrong one, since the second tells anyone who has an account. Login failures get one generic message too, and a different status code or a slower reply can leak the same thing.
• Password length. Enforce a minimum: OWASP counts fewer than 8 characters as weak when the account has multi-factor authentication, and fewer than 15 without it. Allow at least 64, and check new passwords against a list of breached ones.
• Too many attempts. Limit failed logins. OWASP ties the lockout counter to the account rather than the IP address, and treats a CAPTCHA as an extra layer, one you can ask for only after a few failures.
• Password reset. The Forgot Password Cheat Sheet asks for the same message and the same response time whether or not the account exists. Reset tokens are random, single-use and expire. Nothing on the account changes until a valid token is used, and the user gets an email once the password has changed.
• Multi-factor authentication. The cheat sheet calls it “by far the best defense” against most password attacks. If you offer it, test enrolment as part of the signup.

What an AI user adds

• A first pass with no context. It has never seen your product, so it hesitates where a stranger might.
• Every step on the record. The replay shows what it saw, did and thought at each step, so a hesitation has a place you can point to.
• Your real signup, not a mock-up. It works on the live site with the email and password you put on the credentials card.
• The same task after a fix. Run the template again and compare the two replays and their TRACES scores.

Where it stops

• It has no inbox or phone of its own. When Menso recognizes a page asking for a verification code, by email or by SMS, the run pauses until you paste it (or the emailed link), for up to two hours; if it does not recognize the page, the AI user decides on its own what to do. A CAPTCHA that Menso recognizes also pauses the run. You can skip the step or stop the test, and the run ends after ten minutes if you do neither.
• It signs up with email and password only. Google sign-in on your product is not supported yet.
• Test only products you own or have permission to test, with an account made for testing: the AI user acts with the credentials you give it.
• One persona, one run. It shows one path through your signup, not how everyone moves through it.

Two real runs, and what they show

These public runs used Menso's Purchase intent template, not Sign up & log in: the AI user decided whether to sign up and stopped before any form. They show the step just before a signup form, where a visitor decides whether to start at all. One said yes; one said no after the usual pricing address returned a not-found page.

The board's review kept only two week-38 runs for citing, each with a qualification shown as its note, so n=2. Read them as examples, not as a rate. The Product Hunt board has the whole week.

Every run here used Menso's Purchase intent template: the persona Zainab Salazar, a freelance UX consultant, reads the homepage, the pricing page and the FAQ, decides whether she would buy or sign up, and stops before paying. It is a route-specific diagnostic, not a product-wide score.

Made one of these products? Write to support@menso.io and we will correct or remove the example as soon as we can.