How to Test SaaS Demand Before Building: A 10-Day Validation Playbook

If you want to test SaaS demand before writing code, a landing page and a small traffic experiment can produce more useful evidence than another month spent refining a product roadmap. The goal is not to prove that everyone loves your idea; it is to find out whether a tightly defined group will take meaningful action when presented with a clear solution.

The prompt for this approach came from a recent r/SaaS post by u/GrowwirhGrok, who described spending under $200 over 10 days to test a product concept before building it. The method was straightforward: create a page that presents the future product, drive targeted visitors to it, ask for a waitlist signup, test purchase intent, interview respondents, and compare different messages and audiences. (reddit.com)

That is a valuable starting point, but it needs a few important caveats. A click is not demand. A waitlist email is not revenue. And a fake checkout can become deceptive if the customer journey is not handled transparently. The stronger lesson is that founders should build a layered evidence system—one that separates curiosity, urgency, buying intent, and repeatable acquisition potential.

Why founders need to test SaaS demand before building

Most early-stage product mistakes are not technical failures. They are prioritization failures: a founder builds a polished solution for a problem that is either not painful enough, not frequent enough, or not valuable enough for the intended buyer to change behavior.

Building first feels productive because code, designs, and feature checklists are visible outputs. Demand validation feels less comfortable because it forces a founder to expose an unfinished idea to real people and accept the possibility that the market does not care. But that discomfort is useful. It is far cheaper to revise a headline, audience, or price than to rewrite six months of product work.

Testing demand is especially useful for AI tools, developer products, marketing software, and workflow SaaS because these categories are crowded with plausible ideas. “AI for X” can sound compelling in a pitch deck while remaining too generic for a buyer who already has an established workflow, budget constraints, security concerns, or a stack of existing subscriptions.

A good pre-build test answers four questions:

1. Is the problem real? Do people describe it in their own words, without being led by your pitch?
2. Is the proposed outcome compelling? Will they exchange attention, contact information, time, or money for the promise?
3. Is there a reachable niche? Can you identify a specific segment that converts better than the broad market?
4. Is there a viable business model? Does the expected willingness to pay support the cost of acquiring and serving customers?

The distinction between these questions matters. A market can have a real problem but reject your framing. Your framing can earn signups but fail at pricing. A niche can love the product but be too expensive to reach with paid acquisition. Treat validation as a sequence of hypotheses, not a single pass/fail number.

The original low-cost validation experiment

The r/SaaS post outlined a lean experiment that many founders can adapt in a matter of days. Rather than produce an MVP with incomplete functionality, the creator first produced a landing page that described the outcome as though the product were available.

Visitors encountered a specific call to action—joining a waitlist—rather than a passive “learn more” option. The experiment then measured visitor-to-signup conversion, followed up personally with every respondent, asked what they would expect to pay, and added a purchase-oriented CTA to gauge stronger intent. The creator also tested multiple messaging angles and compared results across prospective audiences before deciding whether to build. (reddit.com)

There are three smart principles embedded in that workflow.

It asks for behavior, not compliments

People are generally generous with encouragement. Ask, “Would you use an AI reporting assistant?” and many people will say yes. Ask them to give an email address, book 20 minutes, share their current workflow, or place a refundable pre-order, and the number falls quickly.

That decline is not bad news. It is the point of the test. Every additional commitment filters out lower-intent responses and reveals which prospects feel the pain sharply enough to act.

It tests positioning before implementation

Early founders often assume they need to solve the entire technical problem before learning what buyers value. In practice, positioning can be validated much sooner. A landing page can test whether a buyer cares more about speed, accuracy, compliance, cost reduction, revenue growth, or workflow simplicity.

For example, an AI tool that summarizes customer calls could be positioned as:

• “Turn every sales call into CRM updates automatically.”
• “Find objections and churn risk before the deal is lost.”
• “Give product teams searchable customer evidence without manual notes.”

Each promise points to a different buyer, budget, job-to-be-done, and competitive alternative. One product concept may survive, while two positioning angles fail. That is useful information before engineering begins.

It makes qualitative research part of the test

The original poster’s decision to contact every signup is arguably more important than the ad spend. Quantitative data tells you that someone acted. Interviews explain why they acted, what they expected, what they currently do instead, and what could stop them from buying.

If 20 people join a waitlist, do not simply celebrate 20 leads. Ask what triggered their signup, when the problem last happened, what workaround they use today, what that workaround costs, who approves purchases, and which outcome would justify switching. Those answers are raw material for the product, pricing page, onboarding flow, and sales process.

A better demand-validation ladder: from attention to payment

The biggest risk in a quick test is over-interpreting a weak signal. A paid click is weaker than a signup. A signup is weaker than an interview. An interview is weaker than a calendar commitment, a letter of intent, a paid pilot, or a legitimate pre-order.

Use a validation ladder instead of treating every action as equivalent:

1. Impression: Someone saw your ad, social post, or search listing.
2. Click: Your message generated enough interest to earn attention.
3. Landing-page engagement: The visitor read, scrolled, viewed pricing, or interacted with the page.
4. Lead conversion: They joined the waitlist, requested access, downloaded a relevant resource, or submitted a work email.
5. Conversation: They reply, answer research questions, or book a call.
6. Commitment: They agree to a pilot, provide a use case, introduce a decision-maker, or set implementation criteria.
7. Financial intent: They accept a price, submit a deposit, complete a pre-order, or sign a contract.
8. Retention signal: After access, they repeatedly use the product or keep paying for it.

A small experiment rarely reaches the final stage, and it does not need to. But a founder should be honest about where the evidence sits. Ten ad clicks do not validate a company. Ten buyers who agree to a paid design partnership may validate a much narrower, more actionable opportunity.

The right question is not, “Did anyone click?” It is, “What is the strongest action this audience will take, and what must be true for them to take the next one?”

Build a landing page that tests one clear promise

A demand-test page is not a full marketing site. It is a controlled experiment. Every unnecessary page, feature list, navigation link, and vague value proposition gives visitors more ways to leave without telling you why.

Your page should focus on one audience, one painful job, one differentiated promise, and one primary action. If you are trying to test three audience segments, build separate versions or use clear campaign-level segmentation. Do not write a broad page that says it is for “founders, sales teams, agencies, creators, and enterprises.” That only ensures your results are hard to interpret.

The essential page structure

A practical validation page usually needs:

• A specific headline: Name the audience and outcome.
• A short problem statement: Make the current cost or friction recognizable.
• A concise explanation of the proposed solution: Show the new workflow or result, not a long feature catalog.
• Credibility cues: Founder background, an example workflow, prototype screenshots, sample output, or a transparent “currently in development” note.
• A primary CTA: Join the pilot, request early access, book a research call, or reserve a founding-customer spot.
• A lightweight qualification form: Ask for role, company type, current tool, problem frequency, or budget range when appropriate.

Consider this weak headline:

AI automation for modern teams.

It is broad, undifferentiated, and impossible to evaluate. A visitor may click simply because “AI automation” sounds generally interesting.

Now consider a testable alternative:

Turn agency client briefs into approved campaign plans before the kickoff call.

That version gives an agency owner enough context to self-select. If it converts, you have learned something about a very particular problem and audience.

Avoid building a page that manufactures demand

A persuasive page is not automatically a valid page. If the language uses false scarcity, hides material limitations, overstates automation, or implies that a product is currently available when it is not, you may get more conversions while learning less about durable demand.

Consumer regulators have increasingly focused on how interface design and choice architecture can influence decisions. The UK Competition and Markets Authority’s work on online choice architecture emphasizes that how options, prices, and calls to action are presented can create consumer harm when design is used manipulatively. (gov.uk)

For a pre-build SaaS test, the practical standard is simple: be ambitious about the proposed outcome but transparent about product status. You can say “Apply for the early-access pilot,” “Founding cohort opens soon,” or “We are validating this workflow with a limited group.” You do not need to undermine the test by leading with disclaimers, but you should not make people believe they are buying finished software if they are not.

Paid ads can test message-market fit—but not the whole market

The Reddit post’s $50 ad experiment resonated because it makes validation feel accessible. It also sparked an important community objection: a fixed budget will not produce meaningful results in every category. In expensive B2B keywords, legal software, cybersecurity, healthcare, fintech, or enterprise AI, a $50 budget may yield only a few clicks.

That criticism is correct. Budget is not a universal benchmark; it is a function of cost per click, audience size, campaign quality, conversion rate, and the value of a learning cycle. Google itself notes that Keyword Planner provides keyword ideas, traffic estimates, and average costs, while actual campaign performance can vary based on many factors. (support.google.com)

The better principle is: spend enough to get a meaningful number of qualified visits, not enough to satisfy a round-number rule.

Choose the channel based on the hypothesis

Different acquisition channels reveal different kinds of demand:

Search traffic is particularly valuable when the question is whether people are already seeking a solution. Google Ads matches keywords with searches, and Google’s tools provide estimated traffic and keyword data to help plan campaigns. (support.google.com)

But interruption-based ads are still useful. They answer a different question: when a relevant person is exposed to the promise, does it resonate strongly enough to earn action? That is a legitimate test of positioning, especially for new categories people may not yet know how to search for.

Use organic search data as a second, low-cost test

One of the most insightful replies in the community discussion argued that ads interrupt people, whereas search impressions can reveal what people deliberately typed. That is an important distinction for founders who are testing a problem that may already have clear demand language.

Google Search Console’s Performance report shows search queries, clicks, impressions, click-through rate, and related performance signals for verified sites. Google explicitly positions it as a way to see which queries show your pages in Search and which queries bring traffic. (support.google.com)

For demand validation, this means you can publish pages around the problem—not necessarily your finished product—and observe the language Google associates with the page over time. A page does not need to rank first to generate any signal. However, founders should be realistic: a brand-new domain may need time to be crawled, indexed, and receive impressions, so organic search should complement faster outreach or ads rather than replace them in a 10-day sprint.

How to run a search-intent experiment

Create a useful, specific page around a problem someone might actively search for. If your product is meant to help ecommerce operators reconcile refunds across platforms, publish a page focused on “how to reconcile Shopify and Stripe refunds” or “reduce refund reconciliation errors.”

Then:

1. Verify the domain in Search Console.
2. Request indexing after publishing.
3. Add internal links from any existing relevant pages or profiles you control.
4. Watch query impressions and page-level click-through rate over several weeks.
5. Compare the actual queries with your assumed buyer language.
6. Use those queries to revise your landing-page copy, ad groups, and interview scripts.

Search data is not proof of willingness to pay. But it can expose a gap between what founders call a problem and what buyers call it. That gap matters enormously in SEO, paid acquisition, outbound messaging, and product navigation.

Design the waitlist for research, not vanity metrics

A waitlist is useful only if it creates a path to learning. Collecting 500 unqualified email addresses may look impressive, but it can be less valuable than 15 people who match your ideal customer profile and agree to discuss a real workflow.

The community reaction also highlighted a familiar problem: people join waitlists but do not reply to follow-up emails. This does not necessarily mean the idea has failed. It may mean the signup was casual, the email landed in spam, the sender did not establish context, the ask was too large, or the prospect simply has no urgency.

Improve follow-up response rates

Instead of sending a generic message such as “Thanks for joining—can we chat?”, make your follow-up immediately useful and narrow.

Try this structure:

• Remind them exactly what they signed up for.
• Ask one question that is easy to answer in reply.
• Offer a concrete benefit for participating, such as early access, a workflow audit, a benchmark, or a template.
• Give them two simple response paths: reply with a number, choose a time, or answer a single sentence.
• Follow up once or twice through a second channel only when that channel is appropriate and consented to.

For example:

You joined the early-access list for a tool that turns client-call notes into campaign briefs. Which part currently takes the most time: collecting notes, creating the brief, getting approval, or updating project tools? Reply with one word and I’ll send the workflow template we are testing.

This is easier than asking a stranger to schedule a 30-minute call. It also produces structured data before the conversation begins.

Use double opt-in or a clear consent mechanism where appropriate, and verify submitted addresses before launching a follow-up sequence. A free email address verification tool can help reduce obvious typos and disposable addresses, but it cannot turn low-intent signups into engaged prospects.

Ask pricing questions that produce real evidence

“Would you pay for this?” is among the least useful questions in customer research. Respondents often want to be helpful, and their answer depends on an imagined future product whose scope, reliability, onboarding, and risk they cannot yet assess.

Better pricing research anchors on the current situation.

Ask questions such as:

• What do you use today to solve this problem?
• What does that process cost in staff time, agency fees, software, or lost revenue?
• How often does this happen in a typical month?
• Who owns the budget for solving it?
• Have you evaluated or purchased an alternative in the last year?
• At what price would this be easy to approve, require discussion, or be impossible to justify?
• What result would make this product a clear bargain?

The important word is trade-off. A credible buyer compares your product with a real alternative: manual work, a spreadsheet, a virtual assistant, a consultant, an existing tool, an internal workflow, or doing nothing. Your pricing test should reveal that comparison.

Use price sensitivity carefully

A founder can test several price points through landing-page variants, but pricing pages should not be treated as a simple conversion-rate contest. A lower price may earn more clicks while attracting customers who churn quickly, require more support, or lack the budget authority to adopt the product seriously.

For B2B SaaS, it is often more valuable to test a price range with the right buyer than a low price with the wrong audience. If a workflow saves an agency ten billable hours each month, a $29 plan may signal that you do not understand the value. If it saves a solo creator five minutes a week, a $499 plan is unlikely to survive contact with reality.

Price also shapes the product you must build. Higher price points bring expectations around security, onboarding, integrations, reliability, and support. Testing pricing early helps you avoid a mismatch between the revenue model and the delivery burden.

Fake-door tests are useful only when they are ethical

The original experiment included a “buy now” button to test stronger purchase intent, with honest explanations or refunds when someone tried to complete a purchase. That approach is commonly called a fake-door test: a user sees an option for a feature or product that is not yet available, and their interaction measures demand.

Used carefully, a fake door can be more revealing than a waitlist CTA. It asks visitors to cross a more meaningful threshold. Used carelessly, it damages trust, creates payment disputes, and can create consumer-protection risks.

The safer version of a fake-door test

The safest design is to test intent before collecting money. A purchase CTA can lead to a transparent interstitial or checkout-style screen that states the product is in a limited validation phase, invites the visitor to reserve a founding-customer place, and asks whether they would like to be contacted when the product is ready.

If you take actual payment, it should be a genuine pre-order or deposit with clear terms: what is being purchased, when delivery is expected, whether the charge is refundable, and how to cancel. Stripe’s documentation distinguishes between saving a payment method for a future charge and accepting pre-order payments, which are operationally different choices. (support.stripe.com)

Avoid these practices:

• Charging a card for software that has no realistic delivery plan.
• Hiding that a feature is unavailable.
• Using a purchase flow merely to inflate internal metrics.
• Advertising a price and changing it after collecting customer information.
• Making refunds difficult or slow.
• Treating email submissions as permission for unrestricted marketing.

The test should preserve a relationship with the people who were most interested. Those are potential founding customers, not experimental data points to burn through.

Measure results with enough rigor to make a decision

A small-budget experiment can produce noisy data. Do not pretend that 10 clicks and one signup establish a statistically robust conversion rate. The value of a low-cost test is directional learning: which segment responds, which promise draws attention, what objections appear, and whether deeper actions follow.

Still, you need a simple scorecard. Track each traffic source, audience, headline, offer, and CTA separately. Do not blend results from multiple experiments into one dashboard total.

A practical validation scorecard

For every variant, record:

Focus on qualified conversion rather than raw conversion. A page for “AI social media tools” might generate many cheap waitlist signups. A page for “AI approval workflows for regulated financial-advice content” may generate fewer leads but far more valuable conversations with actual budget holders.

A useful rule: do not choose the biggest audience. Choose the audience with the clearest pain, fastest feedback, most reachable buying process, and strongest evidence of willingness to change behavior.

Run three messaging angles, but change one variable at a time

Testing multiple messages was another strong part of the original framework. Many founders believe they are testing a product idea when they are really testing only one sentence about that idea.

A single message can fail for several reasons: it targets the wrong role, emphasizes a weak benefit, uses unfamiliar language, makes an unbelievable claim, or ignores a deal-breaking objection. Three focused angles can reveal where the value actually lives.

For instance, imagine a SaaS tool that automates post-webinar follow-up. You might test:

1. Revenue angle: “Turn each webinar into qualified sales follow-up in minutes.”
2. Efficiency angle: “Stop manually exporting attendee lists and writing follow-up emails.”
3. Attribution angle: “See which webinars create pipeline, not just registrations.”

Do not change the audience, channel, headline, price, CTA, and visual style all at once. If every element changes, you will not know why one variation won.

A clean test might keep the traffic source, audience criteria, CTA, form, page layout, and price framing constant while changing only the core promise. Once one promise wins, test the next uncertainty: audience, proof, price, or activation offer.

What to do after a promising 10-day test

A promising test is not an instruction to build a full platform. It is an instruction to increase the fidelity of your validation while keeping the scope narrow.

The next move is usually a concierge MVP, a manual service, or a tightly bounded prototype. Deliver the desired outcome for a handful of customers with a combination of spreadsheets, automations, existing AI models, operators, and lightweight code. This lets you discover which parts of the workflow actually matter before you automate them.

For example, if prospects want an AI tool that converts customer interviews into product insights, do not begin by building transcription infrastructure, a full analytics dashboard, role-based permissions, and integrations. First offer a paid or free pilot where customers send five interview transcripts and receive a structured insight report within 48 hours. Watch what they do with it, what they request next, and whether they return with more data.

That process reveals the real product boundary. Perhaps the valuable feature is not analysis but sharing findings in Slack. Perhaps customers want a research repository, not a report. Perhaps the target buyer values compliance controls more than automated summaries. Building manually for a few design partners is often the fastest route to these discoveries.

The biggest mistakes to avoid when validating demand

Demand tests fail when founders optimize for a favorable answer rather than an accurate one. The following mistakes create false positives:

• Targeting friends, peers, and fellow founders instead of buyers. They may admire the idea without needing it.
• Using broad audiences. A vague audience produces vague data and hides high-converting niches.
• Leading interviewees. “Wouldn’t it be great if…” encourages agreement instead of truth.
• Asking only for email addresses. Add paths to deeper commitment, such as a short question, call, pilot application, or price response.
• Ignoring non-response. A large waitlist with almost no replies is a warning about urgency or lead quality.
• Treating one ad platform as the market. Channel fit affects results as much as product appeal.
• Testing a solution without understanding the current workaround. You need to know what people will replace.
• Collecting payment deceptively. Short-term data is not worth long-term trust damage.
• Building too much after the first positive signal. Move from landing page to manual pilot before committing to a large codebase.

The correct outcome of validation is not always “build it.” It may be “target a different role,” “change the pricing model,” “sell a service first,” “find a cheaper acquisition channel,” “solve a narrower workflow,” or “stop.” Any of those conclusions can save months of misdirected work.

Conclusion: demand validation is a learning loop, not a stunt

To test SaaS demand well, use a landing page and small traffic budget as the beginning of a disciplined research loop—not as a shortcut to declare victory. The original r/SaaS experiment is compelling because it prioritizes real-market contact before product development: a specific promise, a meaningful CTA, audience comparisons, direct follow-up, pricing conversations, and evidence of purchase intent. (reddit.com)

The best version of that approach combines paid and organic signals, measures behavior on a commitment ladder, and treats transparency as non-negotiable. Start with the smallest experiment that can disprove your most important assumption. If the result is promising, do not immediately build more software. Increase the quality of the commitment you ask for.

The ultimate validation question is not whether strangers will say your idea sounds useful. It is whether a defined buyer will give you time, context, access, money, or a concrete next step to solve a problem they already feel.

FAQ

How much should I spend to test SaaS demand?

There is no universal amount. A $50 experiment may be enough for low-cost audiences and broad SMB keywords, while a specialized B2B category may require more budget or a different channel. Set a budget based on how many qualified visits or conversations you need to learn something useful, then compare it with expected click costs and conversion rates.

Is a waitlist enough to validate a SaaS idea?

No. A waitlist proves some degree of interest, but it is weak evidence on its own. Follow up with signups, ask about their current process and willingness to pay, and seek stronger actions such as booked calls, pilot commitments, deposits, or pre-orders with clear terms.

Can I test demand before I have an MVP?

Yes. In many cases, you should. A landing page, prototype, mock workflow, manual service, or concierge pilot can test the problem, positioning, audience, and pricing before you invest in a complete product. Be clear about what is available now and what is still being developed.

What conversion rate means a SaaS idea is worth building?

There is no single benchmark because conversion rates depend on traffic quality, product price, urgency, audience, and CTA friction. A lower conversion rate from highly targeted search traffic may be more valuable than a higher rate from broad social traffic. Look for consistent signals: qualified signups, meaningful replies, repeated pain points, budget authority, and movement toward payment.

Should I use a fake buy-now button in a demand test?

You can test purchase intent, but do it ethically. Prefer a transparent reservation or founding-customer flow before charging anyone. If you accept payment, describe it as a real pre-order or refundable deposit, explain delivery expectations, and make refunds straightforward.