Validate a SaaS idea with a waitlist

You do not need a product to learn whether anyone wants one. You need a sentence, a signup box, and a number you can defend in a week. A waitlist is how you measure real intent before you build — not polite interest from friends, not likes on a thread, but strangers leaving an email because they expect something to exist.

Most founders invert the order. They ship a beta, then wonder why nobody converts. Or they run a survey and get eighty "yes" answers that never become a credit card. The proof-before-code habit flips that: publish the promise first, count who opts in, then decide what to build.

Wrong signal

The default validation playbook looks like this: mockup on Figma, post in three Slack communities, ask "would you use this?" in a Typeform. You get warmth. Warmth is cheap.

Warmth does not survive contact with a submit button. A waitlist asks for something people guard — inbox access. If two hundred strangers sign up in ten days from a single LinkedIn post and a bare landing page, you have a different conversation than "my network seems excited."

You might think that is cheating — you are selling vapor. Fair objection. You are not charging yet. You are running a demand probe: one headline, one outcome, one CTA. If the probe fails, you lost a weekend, not six months of backend.

What to put on the page

Strip until it hurts. You need:

• Who it is for (one line, not "everyone")
• What changes when it ships (before → after, in plain language)
• When they get access (rough is fine: "private beta in July")
• One field: email. Maybe name if you will personalize launch emails.

No feature grid. No pricing page. No "about us." Those belong after the probe says go.

Example headline structure that works for B2B micro-SaaS: "Stop exporting Stripe invoices into Excel every month" beats "AI-powered financial workflow platform." Specific pain, specific buyer.

The number that matters

Pick a threshold before you look at the dashboard. Not after.

For a niche B2B tool aimed at solo founders, fifty confirmed signups in fourteen days from channels you did not already own is a serious green light. For a broad consumer idea, you might need five hundred — or you might need ten highly qualified emails from one industry Slack. The threshold depends on who you must reach to make the first ten sales.

Track signup rate, not page views. A thousand visits and twelve signups is a positioning problem. Forty visits and thirty signups is a distribution problem you can solve later.

Log source if you can (?ref=indiehackers, UTM on a tweet). You want to know which story pulled intent, not which story pulled curiosity.

Run the probe in a week

Day 1–2: Write the headline and subhead. Spin up a waitlist — hosted page is enough; you are not optimizing brand yet, you are measuring pull. Tools like followtheduck exist so you are not wiring SMTP, consent text, and export at 11pm.

Day 3: Post where your buyer already hangs out. One primary channel. Repeat the same promise everywhere; do not A/B the thesis yet.

Day 4–7: Reply to every signup if the list is small. Ask one question in the confirmation flow or a follow-up email: "What are you using today?" Their words become your roadmap and your landing page copy.

Day 8: Compare to your threshold. Kill, pivot, or commit. Commit means you can name the first feature from signup pain, not from your notebook.

When to stop probing and start building

Build when the list proves pull and you can articulate the smallest thing that delivers the headline promise. Not when you are bored of marketing. Not when a competitor shipped something noisy.

If signups stall below threshold, change the promise or the audience before you change the stack. Another week on React will not fix a headline nobody wants.

The waitlist is not a launch gimmick. It is the cheapest instrument you own for answering the only question that matters pre-code: will strangers raise their hand?