You can build an app in a weekend now. That is the good news and the trap. When building is this cheap, it is very easy to spend a month polishing something nobody will pay for, and only find out on launch day.
This guide shows you how to test a SaaS idea before you build the real product, using a one-page site, a short waitlist form and a small paid "founding member" offer. It takes about two weeks, costs close to nothing, and works whether you build with Cursor, Claude Code, Lovable, Bolt, Replit or v0.
The core idea is simple: compliments and email signups measure curiosity. Money, time and effort measure intent. Every step below moves people one rung closer to the second kind.
Quick glossary
- Validation: evidence that real people have the problem and will do something (pay, book a call, switch tools) to fix it.
- Waitlist: a list of people who left their email to hear when you launch. Useful, but weak on its own.
- Pre-sell: taking a real payment (or deposit) before the product is finished, with a clear delivery date and refund promise.
- Pass mark: the number you decide in advance that counts as "yes, build it".
- Concierge MVP: delivering the result by hand (spreadsheets, email, you doing the work) instead of with software.
Why a waitlist alone can fool you
On X in October 2026, posts like "How do you validate an idea before wasting months building it?" and "How to filter the 'cool idea' and 'I will use this' fake validation?" drew dozens of replies. On r/SaaS, the most common answer in recent threads is the same: a waitlist shows interest, a payment shows intent.
One r/SaaS founder shared their own numbers in March 2026: about 1,200 waitlist signups turned into 89 trials and 12 paying customers, and the product was shut down. A big list is not the same as buyers.
So we will still build a waitlist. We will just make it ask harder questions, and put a real price next to it.
Step 1: Write your bet and your pass mark before you start
If you decide what "good" looks like after seeing the numbers, anything looks like success. Write the bet down first.
Copy this template into a note and fill it in:
WHO has the problem (be narrow):
WHAT they do today to handle it (tool, spreadsheet, person, nothing):
WHAT it costs them today (time, money, mistakes):
MY OFFER in one sentence:
PRICE I will show on the page:
TEST WINDOW: 14 days, from ____ to ____
PASS (build it): at least __ founding-member payments
OR at least __ people book a call AND describe the problem unprompted
MAYBE (change one thing and rerun): __ to __ qualified signups, 0-1 payments
FAIL (stop or pick a new customer): fewer than __ qualified signups
Hypothetical example: a cafe-owner tool that turns messy shift notes into a weekly summary. Bet: "Owners of 1-3 cafes waste about an hour a week reading WhatsApp shift notes." Pass: 5 founding-member payments at a one-time price in 14 days.
If no result could make you stop, it is not a test.
Step 2: Talk to 10 people who have the problem (without pitching)
Before you build a page, have 10 short conversations with people who match your "WHO". The goal is to learn how they handle the problem today, not to hear that your idea is nice.
The book The Mom Test by Rob Fitzpatrick is the classic guide here. Its main lesson: people are polite about your idea, so ask about their past behavior instead of your future product.
Where to find people: communities they already use, your own network, people complaining about the problem in public posts, and people leaving 2-3 star reviews of existing tools. Follow each community's self-promotion rules and ask for a 15-minute chat, not a sale.
Use questions like these:
1. Tell me about the last time you dealt with [problem]. What happened?
2. How do you handle it today? What tools or people are involved?
3. What is annoying or expensive about that?
4. Have you tried to fix it? What did you try, and why did you stop?
5. Are you paying for anything to deal with this right now? How much?
6. If you could wave a magic wand, what would be different?
7. Who else should I talk to about this?
Avoid "Would you use an app that...?" and "Would you pay for this?". Polite people say yes.
After each call, write down the exact words they used to describe the problem. You will reuse them on your page in Step 3.
Good signs: they have already tried to fix it, they pay for a half-working workaround, or they ask "when can I try it?" before you mention a product. A bad sign: the problem only appears when you bring it up.
Step 3: Build one honest page in an afternoon
Now build a single page. Not the app. Just the promise, the price and the next step.
Paste this prompt into Lovable, Bolt, v0, Replit, Cursor or Claude Code (edit the brackets first):
Build a single landing page for a product that is NOT built yet. Keep it honest.
Audience: [who, in their words]
Problem (use these exact customer phrases): [2-3 quotes from my calls]
Offer: [one sentence outcome, not features]
Sections, in this order:
1. Headline: the outcome for this audience. Subheadline: how it works in one line.
2. "Sound familiar?" with the 3 customer phrases as bullet points.
3. How it will work: 3 short steps.
4. Pricing: show the real planned price: [price]. Under it, a "Founding member" box:
[founding price], limited to [number] spots, delivery by [date],
full refund if I do not deliver or you are not happy in the first 30 days.
Button: "Become a founding member" linking to [payment link URL].
5. Waitlist form for people not ready to pay (fields in the next prompt).
6. FAQ: "Is this built yet?" (answer honestly: in progress, ship date [date]),
"What if it never launches?" (full refund), "Who is building this?" (me, [name]).
Rules: no fake testimonials, no fake user counts, no fake logos, no countdown timers.
Mobile first. One page only. Plain, friendly language.
Two things matter most. First, show a price. If the first time people hear the price is launch day, you never tested the price. Second, say plainly that the product is not built yet, so nobody feels tricked later.
Step 4: Make the waitlist form ask one hard question
A plain email box tells you almost nothing. Add two or three short questions so you can tell buyers from tourists.
Email (required)
What do you use today to handle [problem]? (short text, required)
How often does this happen? [Daily / Weekly / Monthly / Rarely]
Can I email you a few questions or book a 15-min call? [Yes / No]
The "What do you use today?" answer is gold. "Nothing, it is not a big deal" is a tourist. "A spreadsheet my assistant updates every Monday" is a potential customer.
No-code option: Tally's free plan includes unlimited forms and submissions under its fair-use guidelines, as of October 2026, and you can embed the form or link to it.
Code option: ask your AI builder to save signups to a database table. If you use Supabase, ask for a table where anonymous visitors can only insert rows and never read them, so nobody can download your waitlist. Our earlier guide on locking down Supabase covers insert-only tables: https://dev.to/siteory/your-vibe-coded-app-might-be-leaking-user-data-heres-how-to-lock-down-supabase-in-30-minutes-327k
Send every new signup a short personal email from your own address within a day. Ask one question: "What made you sign up?" The replies are often more useful than the form.
Step 5: Add a real founding-member offer with a payment link
This is the step that turns interest into evidence. You do not need checkout code. A Stripe Payment Link is a hosted payment page you create in the Stripe Dashboard and share as a URL.
Useful settings from Stripe's docs, as of October 2026:
- Product type: a one-time payment is simplest for a pre-sale (for example, "Founding member: first 6 months"). Payment Links also support subscriptions if you prefer.
- Limit the number of payments: Stripe can deactivate the link automatically after a set number of payments, and you can customize the message shown afterwards. Perfect for "20 founding spots".
- Custom fields: add one short text field such as "What do you most want this to do for you?". Stripe's docs say not to use custom fields for sensitive personal data.
- Store policies: you can show your refund policy and support contact on the payment page.
Founding-member copy you can adapt:
Founding member - [Product name]
[Founding price], one-time. Covers your first [6 months / 1 year] once it launches.
- Delivery: first working version by [date]. I will email you progress every 2 weeks.
- Refund: full refund if I do not deliver by [date], or within 30 days
of launch if it is not useful. Just reply to any email.
- You get: [main outcome], direct access to me, and a say in what gets built first.
Only [number] spots. The regular price at launch will be [price]/month.
Keep your refund promise fast and without arguments. And know that, per Stripe's refund docs, Stripe's processing fees from the original payment are not returned when you refund, so a refund costs you a little. That is a fine price for real evidence.
Not ready to charge? A weaker but useful version is a booked call, or a concierge offer where you deliver the result by hand for a small fee. A January 2026 r/SaaS thread on validation ranked pre-selling and concierge offers above a plain waitlist.
Step 6: Send traffic from where your buyers already are
A test page with zero visitors proves nothing. Aim for a small number of the right people rather than lots of random clicks.
In order of usefulness:
- The 10 people from Step 2. Send each a personal note: "You told me about [problem]. I am building this. Here is the page and the founding price. Honest feedback welcome, including no."
- Communities where the problem gets discussed. Share what you learned from your calls, not a link dump. Follow each community's promotion rules.
- Your network and one-to-one messages to people who match the "WHO" exactly.
- Optional small ad test. Only if you already know where the audience hangs out, with a small fixed budget you are happy to lose.
To know which source works, give each one its own link with UTM tags, for example ?utm_source=reddit&utm_medium=community&utm_campaign=validation. Stripe's docs say Payment Links accept UTM codes, and that they are passed through to your redirect URL after payment if you set the confirmation behavior to "redirect". Keep a simple sheet:
date | source | visits | waitlist signups | "what do you use today" answers that sound real | calls booked | payments
Step 7: Score the result and decide (build, change, or stop)
At the end of your 14 days, open the note from Step 1 and compare. Do not move the pass mark now.
PASS -> Build the smallest version that delivers the main outcome for your payers.
Email them weekly. They are your first users and your best testers.
MAYBE -> Change ONE thing and rerun for 7 days:
- lots of visits, few signups: the headline/problem is wrong
- signups, no payments: price, offer, or trust is wrong (talk to 5 signups)
- payments, then refund requests: the promise does not match the need
FAIL -> Stop building this version. Keep the notes. Try a narrower customer
or the adjacent problem people kept mentioning in your calls.
Then email everyone who signed up but did not pay: "Thanks for joining. Honest question: what stopped you from grabbing a founding spot?" The answers tell you which "MAYBE" case you are in.
Stopping is a good outcome too. Two weeks to learn "not this" beats six months of building.
Common mistakes
- Counting signups as validation. A big list with no money and no calls is curiosity. Weigh payments and booked calls far above emails.
- Hiding the price. People assume free. Show the planned price from day one.
- Pitching in your interviews. If you talk about your idea in the first ten minutes, you will only hear compliments.
- Asking friends and other developers. They are kind and rarely your customers. Talk to people who have the problem.
- Building the app "just to test". If AI can build it in a weekend, you will be tempted. Build the page first. The app can wait two weeks.
- Fake proof. No invented testimonials, user counts or "only 2 spots left" when it is not true. It breaks trust and, in many places, consumer rules.
- Vague refund terms. If you take money before delivery, state the date and the refund rule in plain words, and honor them quickly. (This is general guidance, not legal advice.)
- Moving the pass mark. Decide the numbers before the test, not after.
Your action summary
- Day 1: Fill in the bet and pass-mark template. Pick a narrow "WHO".
- Days 2-5: Have 10 no-pitch problem conversations. Save their exact words.
- Day 6: Build one honest page with the AI prompt. Show the real price.
- Day 6: Add a waitlist form with "What do you use today?".
- Day 7: Create a Stripe Payment Link for a limited founding-member offer with a clear delivery date and refund promise.
- Days 7-13: Send personal notes to your 10 people, share learnings in 1-2 communities, track each source with its own UTM link.
- Day 14: Score against your pass mark. Build, change one thing, or stop.
The goal is not to prove your idea is good. It is to find out, cheaply and quickly, whether strangers care enough to pay, so the next thing you ask your AI to build already has customers waiting for it.
