How to Validate a SaaS Idea Before You Build It (2026)
A four-week plan to find out whether people will pay for your subscription idea: problem interviews, a one-page offer, real pre-orders and a concierge pilot, with the signals that mean go, change or stop.
Key Takeaways
- Validate the problem before the solution. Ask people what they did the last time the problem happened, not whether they would use your idea.
- Compliments are not evidence. “Great idea” costs nothing to say. Time, introductions and money are the signals that count.
- Ask for money early. A Stripe Payment Link can sell a subscription with no code, so you can take real pre-orders before the product exists.
- Do the work by hand first. Serving a few customers manually shows you what the software must do and proves they will pay for the result.
- Set your stop rules in advance. Decide before you start what result would make you change the idea or drop it.
Quick-Start Prioritization Framework
| Week | Do this | Go signal |
|---|---|---|
| 1 | 10 to 15 problem interviews with one specific type of customer | Most describe the problem unprompted and have tried to fix it |
| 2 | One-page offer with a price and a waitlist or pre-order button | A meaningful share of visitors join or click the price |
| 3 | Ask interviewees and waitlist for pre-orders or a paid pilot | Several people pay, or commit with a deposit |
| 4 | Deliver the result by hand (concierge) for the first customers | They use it, ask for more and renew |
Building software has never been cheaper or faster, which makes it tempting to skip straight to the product. But the most expensive part of a failed SaaS was never the code; it was the months spent on something nobody needed. Validation is how you find out, cheaply, whether a specific group of people has a problem painful enough to pay for every month. This guide gives you a four-week plan that ends with money, not compliments: interviews about real past behavior, a one-page offer, pre-orders through a payment link, and a hands-on pilot. Each step has a clear signal that tells you whether to continue.
Pick a narrow customer and a specific problem
Validation fails most often because the idea is too broad to test. “Small businesses that need better scheduling” could be anyone. “Independent physiotherapists who lose income from no-shows” is someone you can find and talk to this week.
Write a one-line hypothesis
Use this shape: “[Specific customer] struggles with [specific problem], currently handles it by [workaround], and would pay [price] a month to make it go away.” Every later step tests one part of that sentence.
Prefer problems with money attached
Problems that cost the customer money or billable time are easier to sell than problems that are merely annoying. A no-show costs a physiotherapist a paid hour; that makes a $29 a month reminder tool easy to justify.
Week 1: problem interviews that don’t lie to you
People are kind. If you describe your idea and ask whether they would use it, most will say yes. That answer tells you nothing.
Ask about the past, not the future
Y Combinator’s talk “How to talk to users”, given by partner Eric Migicovsky and based partly on Rob Fitzpatrick’s book The Mom Test, encourages founders to ask about specific things people have already done rather than hypotheticals. Questions about past behavior are harder to answer politely and falsely.
- Tell me about the last time this happened. What did you do?
- What was hardest about it?
- What have you tried to fix it? What did that cost?
- Why didn’t those solutions work well enough?
- Who else deals with this, and could you introduce me?
Don’t pitch
Hold back your idea until the end, if you mention it at all. The moment you describe your solution, the conversation becomes about being nice to you. Listen far more than you talk, and write down exact phrases people use; they become your marketing copy later.
Where to find people
Start with your own network, then go where the customer already gathers: industry forums, professional groups, local associations, social media communities. A short, specific message works best: who you are, that you are researching one problem, and a request for 20 minutes. Offer nothing for sale.
What a good week looks like
After 10 to 15 conversations, look for patterns. Strong signals: people raise the problem before you mention it, they have already spent money or time on workarounds, and they introduce you to others. Weak signals: interest only after you explain the idea, no current workaround, “I’d probably use that”.
Week 2: a one-page offer with a price on it
Interviews tell you the problem is real. A page with a price tells you whether strangers care enough to act.
What the page needs
A headline in your customer’s own words, three outcomes they get, the monthly price, and one call to action: join the waitlist, book a call, or pre-order. Showing the price is the point; a waitlist without one measures curiosity, not demand.
Send it to the right people
Share it with everyone you interviewed, post it where your customers gather, and if you have a small budget, run a short targeted ad. Track how many people visit, how many click the price or call to action, and how many leave an email.
Be honest about timing
Say clearly that the product is in development and when you expect to deliver. A pre-launch offer is ordinary; implying a product exists when it doesn’t erodes trust and creates refund requests.
Week 3: ask for money
This is the step most founders skip and the one that matters most. Someone paying is the strongest evidence you can get before launch.
Pre-orders with a payment link
Stripe’s documentation describes Payment Links as a way to accept payments online without writing code, and lists subscriptions among the things you can sell with them. Create a link for a founding-member price, share it with your most interested interviewees, and refund anyone who asks if you don’t deliver.
Founding-member offers
A common approach is a discounted price locked in for early customers, or a paid pilot for a fixed period, in exchange for feedback and patience. Keep it simple: one price, one period, a clear promise of what they will get and when.
Know the fees on a small charge
At Stripe’s published US rates of 2.9% + 30¢ per card charge, a $29 pre-order costs about $1.14 to process. Stripe’s refund documentation says processing fees aren’t returned if you refund, so a handful of refunds costs a few dollars, which is cheap evidence.
Interpreting the result
If several people from your interviews pay, you have a real signal. If everyone was enthusiastic but nobody pays, ask the closest few why. Their answer (price, timing, trust, wrong problem) tells you what to change.
Week 4: deliver it by hand
Before you build software, deliver the outcome manually to your first few paying customers. This is often called a concierge pilot.
Why manual first
Doing the job yourself, with spreadsheets, email and calendar reminders, shows exactly which steps matter and which customers don’t care about. It also proves they value the result enough to keep paying, which is what a subscription depends on.
Worked example
For the physiotherapist reminder idea: each morning, you check three clinics’ booking sheets and send reminder texts by hand. After two weeks you know how many no-shows were prevented, which message wording works, and which clinics would renew. That list becomes your first software spec.
Reading the signals: go, change or stop
Decide your thresholds before you start, so the results can’t talk you into anything.
| What you see | What it likely means | Next step |
|---|---|---|
| Problem raised unprompted, workarounds paid for, people pay | Real, valued problem | Build the smallest version that replaces your manual work |
| Problem is real but nobody pays at your price | Price, packaging or buyer is wrong | Test a different price or a different decision-maker |
| Interest only after you explain the idea | Nice-to-have, not a pain | Go back to interviews; look for a sharper problem |
| Customers want something different from what you offered | The real problem is next door | Re-run week 1 around the new problem |
| Nobody responds to outreach | Wrong channel or wrong customer | Try a different group before judging the idea |
Common mistakes
Almost every one of these trades real evidence for a comfortable feeling.
- Asking “would you use this?” and counting the yeses.
- Interviewing friends and family who don’t have the problem.
- A waitlist with no price, then treating sign-ups as demand.
- Building for months before a single person has paid.
- Targeting “everyone” so no message feels written for anyone.
- Ignoring the workaround people already use, which is your real competitor.
- Moving the goalposts after the results arrive.
After validation: build the smallest paid version
Once people pay and your manual process works, build only what replaces your manual steps, plus sign-in and billing. Everything else waits for customer requests. If you’d rather not code it yourself, Floot can build that first version from a plain-English description, with sign-in, a Postgres database and subscriptions through Floot Payments (paid out via Stripe), and it is free to start.
Frequently Asked Questions
How many customer interviews do I need?
Ten to fifteen with one specific type of customer is usually enough to see whether a pattern exists. If answers are all over the place, your customer definition is probably too broad.
Can I take pre-orders before the product exists?
Yes, as long as you are honest that it is in development, give a delivery estimate and refund anyone who asks if you don’t deliver. Stripe Payment Links let you sell a subscription with no code.
What counts as validation for a SaaS idea?
Strangers paying, or committing real resources such as a deposit or a signed pilot, for the outcome you promise. Interest, likes and waitlist sign-ups without a price are weaker signals.
Should I build an MVP to validate?
Usually not first. Interviews, a priced offer and a manual pilot are faster and cheaper. Build once people have paid and you know which manual steps the software must replace.
What if people say they love it but won’t pay?
Ask the most enthusiastic few why not. The answer is usually price, timing, trust or that the problem isn’t painful enough. Each points to a different change.
Is validation still worth it when AI can build an app in a day?
Yes. Faster building lowers the cost of code, not the cost of months spent marketing and supporting something nobody needs. Validation is about the customer, not the software.
Sources
- Y Combinator, How to talk to users (Eric Migicovsky) https://www.ycombinator.com/library/Iq-how-to-talk-to-users
- Rob Fitzpatrick, The Mom Test https://www.momtestbook.com/
- Stripe Docs, Payment Links, 2026 https://docs.stripe.com/payment-links
- Stripe, Pricing, 2026 https://stripe.com/pricing
- Stripe Docs, Refund and cancel payments, 2026 https://docs.stripe.com/refunds