Pre launch landing page: check the waitlist step

You joined your own waitlist once, from a browser that remembers your details, and the confirmation landed in the inbox you read every morning. A stranger has none of that. They type an address they use at work, the form may reject a plus sign or a stray space, and the confirmation may land in a spam folder or never leave at all. The next failure sits on the thank you screen. It says thanks, but it does not say whether a click is still needed or who will write to them. Each of these looks like success from where you sit, so nobody fixes it.

• The email field accepts an address with a plus sign and saves it as typed.
• The confirmation email arrives, names the product and comes from a sender the visitor recognizes.
• The thank you screen says what happens next and whether a click is still needed.
• A second join with the same address gives a message a stranger can read.
• The form works on a phone, with the keyboard open and the Join button still in view.

The waitlist form saves an address, sends a confirmation and shows a thank you screen. Each job can fail while the other two look fine. A form that saves the address but sends nothing looks finished on screen, and so does one that sends the message to a mistyped address, because the page said thanks before the server answered. Owners rarely see either failure from inside, since their own address was saved long ago and the confirmation they got was already in the inbox they check. A stranger's signup is the only way to see the whole chain at once.

Run the signup on a staging or preview address, so test entries stay out of the list you will launch with. Give each visitor the task of joining with its own email. Then open the confirmation from a test signup of your own and read it against the page. The subject, the sender and the promise should match what the form said.

Landing page testing

A visitor who joins a waitlist has made a small promise. They want to hear when the product is ready, and they are not buying yet. So the thank you screen has one question to answer: will this company write to me, and when? A screen that says only thanks answers neither. Name the sender and the next step, including whether a confirmation link is needed and what arrives after it. If you have no launch date, say so, and name what the person gets meanwhile. A vague promise leaves the visitor waiting for an email that may never come.

Compare the thank you screen with the first screen the visitor saw. If the first screen offered early access and the thank you offers a newsletter sign-off, the visitor cannot tell whether they were enrolled, so they assume they were not. Put the same offer on both screens, in the same words, so a visitor who signed up can see for themselves that they did.

A pre launch page is written weeks before the email it leads to, and the two drift apart. The page says early access for design teams. The first email, written in a hurry, offers a free trial to anyone who joined. A visitor who reads both sees two products and two offers, and leaves the list without saying so. Your signup count will not show that loss. Read the page headline and the email subject side by side, and cut any word that one of them uses and the other never explains.

Pre launch pages get edited right up to the day the beta opens. The headline changes, the thank you copy gets rewritten and the email moves to a new sender, and each change can break the signup again. Rerun the same visitors after every edit, on a preview address, and read the confirmation each time. Each preview deploy can be checked before it goes live.