Guide
How to add a waitlist (with referral codes) to a static coming-soon page
A coming-soon page with an email box is a form, plus a little product policy. You need to accept an address, avoid collecting it twice, tell the person they are on the list, and — if you want a simple growth loop — give them a code to share. All of that can sit behind a static page.
The data you actually need
At minimum: a normalized email, a timestamp, and a status (active vs spam vs deleted). Everything else is optional. A first name is nice. A “what describes you?” select is useful if you will actually read it. A referral code issued to that row, and an optional referred_by pointing at someone else’s code, is enough for a leaderboard.
Do not invent a formal “place in line” that you then secretly shuffle. If you show a position, compute it as “how many non-spam signups happened at or before this timestamp.” People can live with a number that only moves when someone else joins.
Referral codes that humans can read aloud
Eight characters is plenty. Use an alphabet that omits 0, O, 1, and I. Store the code on the original row, and require that a referred_by value match an existing, non-spam code. Ignore self-referrals (the same email using its own code). When someone visits /join?ref=K7Q2MDVX, pre-fill a hidden field so they do not have to type it.
Referrals will be gamed if the prize is good enough. A disposable-email blocklist is a start. If a referral actually unlocks something valuable, consider counting it only after the new address has confirmed they own the inbox. That is a small extra state machine; it is worth it once money or access is on the line.
The static-page mechanics
The page is still just HTML. It POSTs to a Worker (or another tiny backend) that applies the same spam stack you would use on a contact form: Turnstile Siteverify, a honeypot, a timing trap, an origin allowlist, and a rate limit. On success, either:
- Redirect to a thanks page with
?position=17&ref=K7Q2MDVX, or - Return JSON and let the page render the position without a round trip.
If the email is already on the list, return the existing position and code instead of inserting a second row. That single rule prevents most “I refreshed and now I am on the list twice” support mail.
What to tell people, and what not to store
Say that they are joining a waitlist, not a newsletter — unless they also ticked a clear, separate marketing box. Keep confirmation mail short, and mention why they are receiving it. Store a hashed IP if you need it for abuse, not the raw address, and have a way to delete a row if someone asks. This is operational hygiene, not legal advice; if you need a legal view of email collection where you operate, ask a professional.
A kit, if you do not want to write it
Formharbor includes a waitlist form that issues codes, reports position, de-duplicates by email, and shows top referrers in the dashboard, on top of the same Worker that runs a contact form and an optional file upload. The article above is enough to build the same idea yourself. The kit is there if you would rather ship the coming-soon page this afternoon.