# A waitlist page that collects early users

> Build a pre-launch page that says what is coming and collects real, confirmed sign-ups.

Canonical: https://abacklaunch.com/prompts/waitlist-landing-page
Last updated: 2026-10-26

Version 1.0.

Before the production site launches, a waitlist turns early interest into people you can email on launch day. Build a waitlist page that says clearly what is coming and for whom, collects confirmed email sign-ups safely, and looks good when shared.

Site: not given. Find the production URL in the project config, or ask me.

## Ground rules

1. Read before you write. Explore the parts of the codebase this job touches and tell me what is already in place.
2. Plan, then stop. Give me a numbered plan: what you will change, in which files, and why. Wait for my approval before editing anything.
3. Fix things at their source (the shared layout, the config, the generator), not with one-off patches page by page.
4. Keep the project's conventions: its framework APIs, file layout, naming and code style. Add no new dependency without asking.
5. Where something is already done well, say so and leave it alone.

## You will not

- Edit `.env` files, secrets or API keys, or print their values.
- Deploy, push, merge or publish anything.
- Delete data, or run migrations or scripts against a production database.
- Add tracking, third-party scripts or links to any site I did not ask for.
- Change copy, design or behaviour that this job does not need.
- Publish copy I have not approved.
- Email the waitlist.

## Your stack

- Framework: Work out the framework, router and build output from the project files (package.json, lockfiles, framework config) before planning, and say which you found.
- Host: Work out where the site is hosted from the config files (vercel.json, netlify.toml, wrangler config, Dockerfile, fly.toml) and say which you found.

## Steps

### 1. Say what is coming

Draft a headline that names what the product will do and for whom, a short subhead, two or three concrete benefits, and an honest launch timeframe if I have one. Show me the copy before building.

### 2. Collect sign-ups safely

One email field and one button. Store sign-ups with the date, source (UTM parameters, referrer) and consent; send a confirmation email (double opt-in) through the project's email provider; protect the form with a rate limit and a honeypot field. Say what people will receive and how often.

### 3. Optional: referrals

If I want it, give each confirmed sign-up a personal share link and show how many people joined through it. Count only confirmed referrals, so the list cannot be gamed with fake addresses.

### 4. Share-ready

A unique title and description, a 1200 x 630 share image, a canonical URL, and a thank-you state that suggests sharing. Make sure the page is indexable so people searching for the product find it.

## Done means

- [ ] The page says what is coming and for whom, in copy I approved.
- [ ] Sign-ups are stored with source and consent, and confirmed by email.
- [ ] The form is rate limited and has a honeypot.
- [ ] The page has share tags, an image and a thank-you state.

## Report back

When you finish, give me:

- what you changed, file by file;
- anything you skipped, and why;
- anything I must do by hand (DNS records, dashboards, accounts, deploys);
- how to check each change on the live site.

## Related

- [From waitlist to launch day email](https://abacklaunch.com/prompts/waitlist-launch-email)
- [Social share cards for every platform](https://abacklaunch.com/prompts/social-share-cards)
- [Analytics and UTM attribution for launch day](https://abacklaunch.com/prompts/launch-analytics-attribution)