How to Validate a SaaS Idea Before You Build It

A common way to fail with a SaaS product is to spend a year building something polished and launch to silence. A far cheaper path is to find out whether people will pay before you build much at all.

You don't need a working product to do that. Conversations, a landing page, a clickable prototype and a payment link can tell you most of what you need to know, and they cost far less than months of building. This guide walks through the whole process in order:

1. Define a specific customer and problem
2. Run problem interviews
3. Test an honest landing page
4. Show a clickable prototype
5. Ask for a refundable pre-commitment
6. Deliver by hand before you automate
7. Graduate to no-code tools
8. Read the signals and decide: build, pivot, or stop

It ends with a week-by-week plan you can start this week.

The Honesty Ground Rules

Every technique here works without deceiving anyone, and it should stay that way. Before you start, commit to these rules:

• Never imply the product exists when it doesn't. Label mockups as mockups and say "coming soon" or "pre-order" plainly.
• No fake social proof. No customer logos you haven't earned, no invented testimonials, no made-up user counts.
• No fake scarcity. Only say spots are limited, or that a deadline applies, if it genuinely does.
• Every payment is refundable until you deliver, and you say so up front.
• Report progress truthfully. If you send updates to pre-order customers, describe what you actually did.

Beyond being the right thing to do, honesty protects the signal you're trying to measure. People who pre-order a product they know doesn't exist yet are giving you much stronger evidence than people who were misled. For more on where the lines sit, see Fake Door Tests and Ethics.

What Doesn't Count as Validation

Before looking at what works, it helps to know which approaches produce false confidence.

"Visionaries don't validate." It's tempting to point at famous products that supposedly skipped validation. Those stories are usually oversimplified, and they tell you nothing about the many products that failed the same way. Checking your assumptions against real buyers is cheap insurance.

Surveys. Surveys are useful for sizing things you already understand, but weak for validating demand. Saying "yes, I'd pay for that" costs nothing, so answers skew optimistic. Surveys measure politeness more than demand.

Friends and family. People who care about you don't want to hurt your feelings. Their encouragement is sincere, but it isn't evidence that strangers will pay. Unless they are exactly your target customers and would pay you real money, their feedback doesn't count.

Waitlist sign-ups on their own. An email address is cheap to give. Sign-ups tell you the headline is interesting; they don't tell you anyone will pay.

The common thread: opinions are free, commitments are not. Everything below is designed to move people from opinion to commitment.

Step 1: Define the Customer and the Problem

Start with a problem, not a product. Get specific about who has it:

• Too vague: "A project management tool for everyone."
• Specific: "A project management tool for freelance graphic designers who struggle to get client feedback on time."

If you can't name the customer and their specific pain point, you don't have an idea to validate yet.

Define an Early-Adopter Profile

Your early adopters are the people who suffer from this problem the most. That group is narrower than your eventual ideal customer profile, and it should be specific enough that you could search for them. A hypothetical example for a data pipeline tool:

• Data engineers at growing startups
• Managing many data sources
• Already paying for a pipeline tool
• Spending a meaningful amount on it each month
• Publicly frustrated with cost or reliability

The strongest signal is people who complain about a tool they already pay for: they have the problem, they have a budget, and they're motivated to switch.

Where to Find Them

• Subreddits and forums for the profession (search for a tool name plus "expensive", "alternative", or "frustrating")
• X/Twitter advanced search for "[tool] alternative"
• Review sites such as G2 and Capterra, filtered to 1-2 star reviews
• LinkedIn job posts that mention the tools involved
• Slack and Discord communities for the profession
• GitHub issues and discussions on related open-source projects

As you read, record:

• The exact words people use to describe the problem (you'll reuse them in your copy)
• What they currently pay, if they mention it
• What they've already tried

Aim for around 20 people describing the same problem before moving on.

Two Quick Market Checks

You don't need a TAM/SAM/SOM slide to validate an idea. Two quick exercises tell you more.

The 100-customer test. Can you name 100 specific organizations, or specific kinds of teams you could actually find and contact, that would buy this? Not "all SaaS companies" or "SMBs in America". If you can't list them, your market is either too small or too vague to reach.

Work backwards from $10K MRR. Take a revenue goal and divide. These examples assume a 2% conversion rate from prospects to customers; that's an assumption to replace with your own numbers:

Low prices need very large audiences, which usually means B2C-style marketing. Higher B2B prices need far fewer customers, which is why small B2B products often work for solo founders.

Look at the Competition

Competition is usually a good sign: it shows people already pay to solve the problem. Having no competitors at all can mean there's no market. You can learn a lot in an afternoon:

1. Sign up for their free trial
2. Read their worst reviews on G2 or Capterra
3. Search communities for "[competitor] alternative"
4. Join their public community and see what users ask about
5. Read their pricing and sales pages closely, including what they gate behind a sales call
6. Check their job posts, which reveal where they're investing
7. Read their changelog to see how fast they ship

Document what people complain about most (your opportunity), their pricing (your positioning), who they target (your differentiation), and why people leave them (your messaging).

Common positions a small product can take:

• The unbundler: the competitor does 50 things adequately; you do one thing very well.
• The simplifier: the competitor is built for enterprises; you build for small teams that want something simpler (the way Linear positioned itself against Jira).
• The vertical: the competitor is horizontal; you build for one industry's specific workflow.
• The lower-cost option: the competitor is expensive; you offer the features most customers use at a lower price.

For a structured way to work this out, try the positioning workshop for micro-SaaS.

Step 2: Run Problem Interviews

Talk to strangers who have the problem, and ask about their past behaviour rather than their opinions. For a deeper interview guide, see Customer Interviews That Don't Suck.

The Outreach Message

Keep it short, specific, and honest about what you're doing:

Subject: Quick question about your [tool] setup at [Company]

Hi [Name],

I saw your comment about [tool]'s pricing in [community]. It sounded frustrating.

I'm researching how data teams decide whether to build or buy their pipelines.
I'm not selling anything on this call; I'm trying to understand the problem.

Would you have 20 minutes this week? I'm happy to share what I learn from
other teams.

[Your name]

This works because the specific reference shows you did your homework, it's honest about the purpose of the call, it offers something back, and it's short. Don't send the same message in bulk, and respect each community's rules on self-promotion and direct messages.

Track a simple funnel: messages sent, replies, calls booked, and (later) commitments. Where people drop off tells you what to fix.

The Interview Script

Don't ask "Would you use an alternative to [tool]?" Ask about what actually happens. Listen far more than you talk.

Opening (2 minutes)

"Before we start: I'm exploring building something in this space, but I'm not selling anything today. I just want to understand how you work. Is that okay?"

Current state (10 minutes)

1. "Walk me through the last time you dealt with [problem]. What happened?" Listen for specific tools, friction points, and time wasted.
2. "What's the most frustrating part of your current setup?" Listen for emotion; strong frustration signals a real problem.
3. "Could you show me how you use [tool] today? What bothers you most?" Listen for feature gaps, pricing pain, and reliability issues.
4. "Roughly what do you spend on this each month?" Listen for a real budget, not a theoretical one.

Problem severity (5 minutes)

5. "On a scale of 1 to 10, how painful is this problem?" Follow up with "Why not a 10?" and "Why not a 1?"
6. "What happens if you don't solve this in the next six months?" Listen for real consequences.
7. "What have you already tried? Why didn't it work?" Listen for failed solutions and buying triggers.

Solution discovery (5 minutes)

8. "If you could design the ideal solution, what would it do?" Separate must-haves from nice-to-haves.
9. "What would need to be true for you to switch from [tool]?" Listen for switching costs and decision criteria.
10. "Who else would be involved in a purchase like this?" Map the buying process.

Money (3 minutes)

11. "If something solved [the problem they described] and saved you [the cost they mentioned], what would that be worth to you each month?"
12. "Would you pre-pay for the first few months, at a discount, to be one of the first customers?"

Close (2 minutes)

"Based on what you've told me, I'm thinking of building [specific solution]. Would you want to be one of the first customers at $[price]/month?"

If yes, agree on a concrete next step, such as a refundable pre-payment or a card on file that isn't charged until launch. If no, ask: "What would need to change for this to be a yes?"

For the pricing part of these conversations in more depth, see Pricing Discovery Interviews for B2B SaaS.

Step 3: Test an Honest Landing Page

A landing page turns a vague idea into a specific offer you can measure. You don't need a full website: a single page built in a few hours with a no-code builder is enough.

What the Page Needs

• A headline that names the problem in your customers' own words
• A short explanation of how the product will solve it, in three to five bullets
• Mockups, clearly labelled as designs of the planned product
• Pricing, so you test willingness to pay, not just curiosity
• A call to action that states the stage honestly: "Join the waitlist", "Pre-order", or "Reserve a founding spot"
• An email form to capture interest from people not ready to commit

An example structure, for a hypothetical data pipeline product:

Headline: Stop overpaying for your data pipelines

Subheading: [Product] will sync your most-used data sources for a flat monthly
price, with no usage-based surprises. We're building it now.

[Design mockup - labelled "Planned dashboard"]

How it will work:
1. Connect your sources
2. Set your sync schedule
3. Pay one predictable price

Founding customer pricing: $[X]/month (regular price will be $[Y])
- [Number] data sources
- White-glove migration from your current tool
- Fully refundable until launch

Expected delivery: [month/quarter]

[Reserve a founding spot]

The Fake-Door Question

A "fake door" is a button for something that doesn't exist yet, used to measure how many people click it. It can be useful, but only if the page makes the stage obvious, either before the click or immediately after it ("This is coming soon; leave your email and we'll tell you when it's ready"). A button that pretends to start a checkout for a finished product, then shows an error, misleads people and trains them to distrust you. Read Fake Door Tests and Ethics before you run one.

Getting Traffic to It

You don't need a large budget. Two options:

• Share it where your target users gather. Be transparent that you're testing an idea, and follow each community's rules.
• Run a small, capped ad campaign on a platform where your audience is reachable (Reddit or LinkedIn, for many B2B ideas).

Show the page at the end of your interviews too. People who have just described the problem to you are the best audience it will ever get.

What to Measure

Track visits, sign-ups or pre-orders, and where each visitor came from. There's no universal "good" conversion rate, because it depends heavily on the traffic source: a visitor from a targeted community post is not comparable to one from a broad ad. Decide before you start what result would make you proceed, and treat low-intent traffic with caution.

A page that gets traffic but no sign-ups is telling you something about the problem, the offer, or the price. Combine the numbers with what you heard in interviews before drawing conclusions.

Step 4: Show a Clickable Prototype

Once people are interested, a clickable prototype makes the idea concrete. Design tools such as Figma let you link screens together without code.

1. Design the core workflow, not every screen
2. Use your own design, not a copy of a competitor's interface
3. Fill it with realistic example data based on what you've heard in interviews
4. Walk prospects through it on a call, or record a short walkthrough video
5. Say clearly that this is a prototype of what you plan to build
6. Ask for feedback, then ask interested prospects for a commitment

If people ask "When can I start using this?" after seeing a prototype they know isn't real, that's a strong signal.

Step 5: Ask for a Pre-Commitment

Asking for money before the product exists is uncomfortable, and it's where many ideas stall. It's also the most informative step in validation. Interest is easy to express. When you ask for a payment, people suddenly need to "check with the team" or "think about it", and that reaction is the information you need.

Ways to Ask

• Refundable deposit: a small amount to reserve a founding spot, with a founding-customer discount, refunded in full if you don't deliver by a stated date.
• Pre-paid founding plan: the first months or year at a founding-customer discount, fully refundable until launch. Fewer people say yes, but those who do tend to be your most committed customers.
• Letter of intent: a non-binding statement that they intend to buy at $[X]/month. Easy to get and useful for larger B2B deals, but weaker evidence; not everyone who signs will buy.
• Advisory customer: pay upfront, help shape the product in regular calls, and lock in founding pricing. Fewer takers, but very useful feedback from people with skin in the game.

The Follow-Up Email

After a promising interview, follow up while the conversation is fresh:

Subject: Building what we discussed - interested?

Hi [Name],

Thanks again for the conversation. It convinced me this problem is worth solving.

It isn't built yet. Here's what I plan to build, based on what you told me:
- [Specific capability they asked for]
- [How it addresses the pain point they mentioned]
- [The price we discussed]

I'm looking for [number] founding customers. The offer:
- [Discount] off for as long as you're a customer
- A direct line to me
- Real input into the roadmap
- Expected delivery by [date], with a full refund if I miss it

If you're in, here's the payment link: [payment link]

Happy to answer questions by email or on a quick call.

[Your name]

Only mention limited spots or deadlines if they are real.

Taking the Money

Payment links (for example, Stripe Payment Links) let you take payments or card details without building a checkout. State the delivery date and refund terms right next to the payment button, and keep pre-sale money easy to refund until you have delivered.

Before you start asking, decide what result means "build it": for example, a set number of paid commitments by a set date. Deciding in advance stops you from rationalizing weak results later.

Automating the Funnel (Optional)

If interest outgrows the calls you can handle, a simple no-code funnel can qualify leads and take pre-orders:

Landing page → Form → Booking link or recorded walkthrough → Payment link

1. A form asks about the prospect's current tool, what they pay, which features they need, and their contact details
2. An automation tool (such as Zapier or Make) adds them to a database and sends a follow-up email
3. The follow-up includes a recorded walkthrough of the prototype for their main use case, and a payment link
4. Anyone who wants to talk first can book a call

Recording a few walkthroughs for different use cases is fine; just don't present a pre-recorded video as a personal, one-off recording.

Step 6: Deliver by Hand Before You Automate

When people have paid, you don't have to build the full product immediately. Two approaches let you deliver value while you learn what to build. Both depend on being open about what's happening behind the scenes.

Concierge MVP

You deliver the result as a service, openly. For a data pipeline product, that might mean setting up and running each customer's syncs yourself using existing tools, and telling customers that's how it works for now.

What it teaches you:

• Which parts of the job customers actually care about
• Which steps are worth automating first
• What onboarding really involves

Where it breaks down:

• It doesn't scale beyond a handful of customers, and pushing it further leads to burnout
• Quality slips when you're stretched thin
• People may pay for a done-for-you service and not for software, so concierge pricing doesn't validate software pricing; check that separately

Manual Back-End ("Wizard of Oz") MVP

A simple interface on top of a manual process: customers use a basic front-end, and you do the work behind it. A hypothetical example: a scheduling tool for contractors where customers submit requests through a web form, and the founder updates a spreadsheet and sends the results by hand.

This lets you charge real money and learn what customers need before automating anything, with conditions:

• Disclose it. If customers ask how it works, tell them. If your marketing says "automated", it should be. When in doubt, say up front that parts of the service are handled by a person during early access.
• Handle customer data properly. Keep it on secure, properly configured services, not on your laptop, and tell customers where it goes.
• Set expectations about turnaround times and reliability.
• Plan the exit. Decide in advance at what point you'll automate, get help, or stop taking new customers.

Step 7: Graduate to No-Code Tools

Once the manual process is clear, a no-code MVP can replace much of it:

• Front-end: a no-code app builder such as Bubble or Softr, or an internal-tool builder such as Retool
• Database: Airtable or a similar tool
• Automation: Zapier, Make, or Pipedream (Pipedream also lets you add small bits of code when needed)
• Authentication: built into many app builders, or a hosted auth provider
• Payments: Stripe
• Support: a live chat or help desk tool

This stack won't scale forever, but it can carry your first customers while you confirm the business works. Some products run on no-code tools for a long time; others need a rebuild once they grow. For choosing the stack for that rebuild, see The Right Tech Stack for Your Micro-SaaS.

Tools by Job

You don't need all of these. Pick one tool per job, across every step of validation.

Check each tool's current pricing and limits before you commit; free tiers change often.

Pitfalls at This Stage

• Runaway usage bills. A script left running or an automation stuck in a loop can run up a large bill quickly. Set billing alerts and spending caps on every service that charges by usage.
• Overpromising. Under pressure to close a sale, it's easy to promise an integration you've never looked at. Only commit to what you're confident you can deliver, and say "I'll check and get back to you" when you're not sure.
• Burning out on manual work. Manual delivery is exhausting. Stick to the exit point you set.

Step 8: Read the Signals and Decide

Signals Worth Tracking

Opinions are cheap. These signals are harder to fake:

If people aren't frustrated with their current solution, they are unlikely to go through the effort of switching.

Warning Signs That Mean Pivot

Pivots during validation are normal. Three patterns suggest you should change direction rather than persist:

1. The price doesn't hold. You assumed $200/month; people consistently say they'd pay under $50/month; the market math no longer works.
2. The excitement fades. The first conversation is "This is great!", the follow-up is "Still thinking about it", then no reply, and the pattern repeats across several prospects.
3. Every customer wants something different. One needs feature A, another feature B, a third says C is a deal-breaker, with no overlap.

If you see two or three of these, change something significant: the customer, the problem, or the price.

Pivot Toward Specificity

Successful pivots tend to make the product narrower, not broader:

• From platform to single job: a full ETL platform becomes a handful of connectors that work reliably.
• From horizontal to vertical: generic project management becomes project management for one industry.
• From suite to feature: a full analytics platform becomes a tool that does only churn prediction.

If feedback says your product is too broad, listen.

Deciding to Build

You'll rarely get perfect evidence. At some point you decide to build with good-but-incomplete data. Before you do, make sure you have:

• Hit the go/no-go threshold you set in advance
• Several real, paid pre-commitments
• A clearly validated problem, described the same way by different people
• A specific target customer you know how to reach
• A realistic path to your first 10 customers (see From Zero to Ten)
• A first version you can build, or deliver by hand, without a large investment

The difference between a reasonable bet and wishful thinking is usually whether anyone has committed money.

The Emotional Side

Validation is hard on your confidence. You will hear "Why would anyone pay for this?", "Isn't this just like [competitor]?", and "Maybe, but not now." The more people you talk to, the more "no"s you'll collect, and that's fine; you're looking for the few people with a real problem.

Many founders go through a familiar arc: excitement, a reality check, a trough where nobody seems to want it, a glimmer when a few people get genuinely interested, and finally clarity about who wants it and why. The trough is where many people quit. Expect it, and judge the idea on evidence rather than on how you feel that week.

It helps to have an accountability partner (ideally another founder), regular check-ins with someone who will be honest with you, and a written log of what you're learning. Get professional support if the stress is affecting your health. Validating alone makes it easy to drift into wishful thinking or discouragement.

Your 8-Week Validation Plan

Here's a plan you can start this week. If you already know the market well, you can compress it into about four weeks by combining weeks 1-2, 3-4, and 5-6.

Week 1: Setup

• Write your early-adopter profile (one paragraph) and problem hypothesis
• Spend several hours in communities where your target customers talk
• Record the exact words they use and what they pay today
• List 100 target organizations and run the $10K MRR math
• Decide your go/no-go threshold (for example, a number of paid commitments by a date)
• Send 30 personal outreach messages

Week 2: First Conversations

• Conduct 5+ interviews
• Document pain points and rate frustration (1-10)
• Ask about current spending
• Research the main competitors
• Refine your problem hypothesis

Week 3: Go Deeper

• Conduct 10+ more interviews
• Look for patterns across interviews
• Confirm a budget exists and understand the buying process
• Identify must-have features

Week 4: Offer

• Design the smallest useful solution
• Build a landing page with an honest call to action
• Design 3-5 mockup screens of the core workflow, labelled as designs
• Set founding-customer pricing, a delivery date, and a refund policy
• Create a payment link

Week 5: Money Test

• Re-contact interested people and walk them through the prototype
• Send a small amount of targeted traffic to the landing page
• Ask for refundable pre-commitments
• Note every objection

Week 6: Follow Up

• Follow up with every "maybe"
• Adjust the offer if the feedback justifies it
• Close founding customers and document every commitment

Week 7: Decide

• Compare results against the threshold you set in week 1
• Work through your unit economics and revisit your market math
• Make a go/no-go decision
• Tell everyone who took part what you decided

Week 8: Next Steps

• If go: plan concierge or no-code delivery, confirm the delivery date with customers, and start building
• If no: refund any payments, thank everyone, and share what you learned
• If maybe: change the customer, problem, or price, and restart the plan

The Uncomfortable Truth

Most ideas don't survive contact with real customers. Validation isn't about proving your idea is good; it's about finding out quickly and cheaply if it isn't.

Founders who validate well aren't necessarily smarter. They're willing to hear "no" earlier and more often, and they care more about the problem than about their first solution. When you find a problem that frustrates people, that they already pay to work around, and that has a clear buyer with a budget, that's when to build. Deliver by hand before you automate, and automate before you build.

Validating a SaaS idea? When you launch, add it to BuildVoyage and record your milestones, so other makers can learn from how you got there.