Build a pre-launch landing page that captures emails
How to build a pre-launch landing page that captures emails: headline, CTA, waitlist form, and source tracking for early validation.
A pre-launch landing page should do one job: turn curiosity into a clear “yes, tell me when this exists”. That means a specific promise, a single email field, and a durable, spam-resistant place to store addresses. You do not need a product, a login, or a database — only a page that explains the outcome and a form that keeps the signal clean.
What to say above the fold
- Headline — the outcome, not the feature list. Example: “See customer demand before you build the whole product.”
- Sub-head — who it is for, what pain it removes, and how soon they should expect value.
- 3 short bullets — concrete benefits or situations where the product helps.
- One CTA — ask for one thing: an email. Extra fields lower conversion during validation.
- Light proof — a mockup, short clip, or one sentence about how the workflow works.
What not to include yet
- Long feature tours — validation pages sell the promise, not the full roadmap.
- Too many fields — name, company, role, and budget can wait until after the first signal.
- Multiple CTAs — “book a call”, “join Discord”, and “read the docs” dilute the main action.
The form
Host the page anywhere — Framer, Carrd, Cloudflare Pages, or plain HTML — and post the email to the subscribe endpoint. Swap in your public campaign id (pub_…), keep the hidden honeypot field, and tag the source if you plan to test multiple channels. The field reference lives in the quickstart.
<form action="https://simple-signups.com/api/subscribe" method="POST"> <input type="hidden" name="campaignId" value="pub_your_campaign_id" /> <input type="email" name="email" required placeholder="you@example.com" /> <input type="text" name="hp" tabindex="-1" autocomplete="off" style="position:absolute;left:-9999px" aria-hidden="true" /> <button type="submit">Get early access</button></form>What happens after the signup
Tag the source of each signup so you can compare channels, then export to CSV/JSON when it is time to invite. The page is successful when it teaches you whether the promise is working, not when it perfectly represents the final product. If the signal is weak, rewrite the copy before you write more code.
Related
- How to quickly validate an idea with a waitlist — the decision loop behind the page.
- Product waitlists use case — the worked product flow.