How to Validate a SaaS Idea Before Building an MVP
A seven-day field test for founders who want evidence before they spend money on code: better interviews, stronger commitment tests and a clear build, narrow or stop decision.
Api AlamThe short answer
To validate a SaaS idea, find one reachable customer group, study how they handle the problem today, and ask for a commitment that costs more than a compliment. That commitment might be access to real data, a scheduled pilot, an introduction to the buyer, a refundable deposit or payment for a manual version of the outcome.
Validation does not prove that the company will work. It reduces the most expensive uncertainty before you turn a hunch into weeks of product work. The goal is to leave with one of four honest decisions: build a narrow MVP, test another assumption, choose a tighter customer, or stop.
I know why founders skip this. A login screen looks like progress. Five awkward conversations do not. But code is a costly way to discover that the buyer was wrong, the problem happens twice a year or the “must-have” workflow already lives comfortably in a spreadsheet.
If the evidence survives this guide, use the companion articles to plan the MVP development cost and a realistic MVP timeline.
What SaaS idea validation can actually prove
An idea is a stack of assumptions. You assume a person has a problem, you can reach them, your outcome matters, the workflow can be delivered and somebody will pay. A polished prototype can test only part of that stack.
Strategyzer’s approach starts by separating desirability, feasibility and viability, then testing the assumptions with high impact and weak evidence first. That matters because founders naturally test the part they enjoy. Developers test whether they can build it. The first fatal risk is often whether anyone needs it badly enough.
Eric Ries gives this a useful name in The Lean Startup: validated learning. At this stage, progress is not the amount of product you have produced. It is the quality of the evidence telling you whether to continue, change direction or stop.
Problem evidence
Real people describe the same recent pain, not a hypothetical inconvenience.
Customer evidence
You can identify and reach the first users without targeting an imaginary average person.
Value evidence
The proposed outcome improves something they already care about: time, revenue, risk or effort.
Commitment evidence
A buyer gives money, access, reputation or operational effort to move the test forward.
Find the assumption that can kill the idea
Before you make a landing page or interview script, write the idea as a testable sentence: When [specific customer] faces [specific event], they will choose [promised outcome] over [current alternative] because [important advantage].
Now underline the least-supported part. That is the first test. Strategyzer calls this starting with the most critical hypothesis; Steve Blank’s customer discovery work makes the same move by taking value-proposition and customer assumptions outside the building.
Once the interviews point to a real segment, April Dunford’s Obviously Awesome is a practical next read. Its positioning process helps you connect the alternatives customers use today, your differentiated value and the customers most likely to care. That work is stronger after discovery, when the words come from buyers rather than a brainstorm.
| assumption | question | cheapest useful test |
|---|---|---|
| Customer | Can I name one reachable group rather than everyone who might benefit? | Recruit five conversations from one role, industry or situation. |
| Problem | Does this happen often enough, and hurt enough, to change behaviour? | Collect recent stories, current workarounds and the cost of leaving it alone. |
| Outcome | Is the result valuable without every feature in my head? | Offer the outcome manually or show one narrow workflow in a prototype. |
| Reach | Can I repeatedly find buyers without depending on one lucky introduction? | Contact a small list through the channel you expect to use after launch. |
| Payment | Will the person with budget make a meaningful commitment? | Ask for a paid pilot, refundable deposit, preorder or signed next step. |
Interview customers without selling them the answer
The fastest way to ruin a useful interview is to explain the product first. Once people know what you want to hear, kindness takes over. Y Combinator’s user-interview guidance and Rob Fitzpatrick’s The Mom Test both push founders toward specific events in the customer’s life instead of forecasts about an imaginary future.
Speak to people who recently experienced the problem. Ask for the story in order. When did it start? What happened next? Who became involved? Where did money, time or trust leak out? Your idea should stay in your notebook for most of the call.
Five questions worth carrying into every call
- Walk me through the last time this problem happened.
- Where did the current process become slow, risky or frustrating?
- What did you try next, and why did you choose that workaround?
- What does the problem cost in time, money, missed work or customer trust?
- What would have to change for solving it to become a priority now?
avoid
“Would you pay $29 for a tool that automatically fixes this?”
It contains your price, solution and desired answer.
ask instead
“What did you do the last time this happened, and what did that cost?”
It asks for behaviour that already happened.
Use an evidence ladder, not a pile of compliments
Not all positive signals deserve the same weight. A friend saying “great idea” costs nothing. A buyer sharing operational data risks time and reputation. Payment adds a real tradeoff. The further a person moves from saying to doing, the more useful the evidence becomes.
Indie maker Pieter Levels puts the commitment test more bluntly: people paying is the clearest idea-validation signal. I agree with the direction, with one caveat: a first payment proves purchase intent, not repeat usage or retention. Those still have to be earned after launch.
A compliment
weak
They like you or the idea. You have not learned whether the problem changes behaviour.
An email or waitlist signup
light
The promise earned a small action. Useful for messaging, but still easy to abandon.
A specific recent problem story
useful
The pain exists in the customer’s life, with context you can compare across interviews.
Access, data or a scheduled pilot
strong
They are spending reputation or operational effort to help the test happen.
A deposit, preorder or paid manual service
strongest pre-build
The buyer crossed from interest into commitment. You still need to prove usage and retention.
Five useful tests before production code
Choose the test that matches the unknown. Interviews are good for understanding a problem. They are weak at proving someone will adopt a particular workflow. A prototype can test comprehension and usability. A paid manual pilot can test whether the outcome deserves budget.
| test | use it when | look for |
|---|---|---|
| Problem interviews | You are unsure who hurts or why. | Recent examples, repeated language, workarounds and consequences. |
| Landing page offer | You understand the pain but not the message or channel. | Qualified visitors take one honest next step: book, apply or join a specific pilot. |
| Clickable prototype | The workflow or value is hard to explain in words. | Target users can complete the key task and explain where it fits into their day. |
| Concierge pilot | The outcome can be delivered manually before it is automated. | A customer gives real input, receives the result and asks to continue. |
| Paid pilot or deposit | You know the buyer and can state the outcome clearly. | Money, a signed agreement or a concrete purchasing process begins. |
Use the cheapest prototype that fits the learning goal, and treat disposable prototype code as learning material rather than the production foundation. For many B2B ideas, Paul Graham’s manual approach is even cheaper: deliver the result by hand until you understand what deserves automation.
If willingness to pay is the main uncertainty, Stripe Payment Links can accept a one-off or subscription payment without a custom checkout. You still need a clear offer, delivery plan and refund terms; the link only removes code from the test.
My seven-day SaaS validation field test
This is the short process I would use before a scoping call. Seven days is not a universal law. It is a forcing function: one segment, one dangerous assumption and one stronger ask by the end of the week.
Day 1
Write the narrow hypothesis
Name the customer, painful event, current workaround, promised outcome and one assumption most likely to kill the idea.
Day 2
Recruit from one segment
Ask peers, communities and warm contacts for short conversations with people who recently faced the problem.
Day 3
Run problem interviews
Listen for real timelines and consequences. Do not demo, defend or ask whether they like your idea.
Day 4
Follow the strongest trail
Speak to more people who resemble the clearest cases. Ask who owns the budget and what creates urgency.
Day 5
Map the evidence
Group repeated problems, exact customer language, current spending, objections and the assumptions still supported only by hope.
Day 6
Make one honest offer
Propose a manual pilot, prototype session, deposit or paid first result with a clear scope and delivery date.
Day 7
Choose the next test
Build only if the narrow workflow has evidence. Otherwise narrow the segment, change the promise or stop without regret.
Books and essays worth keeping beside this plan
- The Mom Test — Rob Fitzpatrick — For interviews that uncover behaviour without inviting polite, useless praise.
- The Lean Startup — Eric Ries — For treating each release as an experiment designed to produce validated learning.
- Start Small, Stay Small — Rob Walling — For the broader bootstrapped SaaS journey around a focused, reachable market.
- Obviously Awesome — April Dunford — For positioning the validated problem against the alternatives customers already understand.
- Do Things that Don’t Scale — Paul Graham — For learning the workflow manually before deciding what software should automate.
Decide whether to build, narrow or stop
I use the scorecard below as a decision aid, not science. Give each row zero, one or two points. The useful part is not the total; it is seeing exactly where confidence still depends on a story you told yourself.
| signal | 0 points | 1 point | 2 points |
|---|---|---|---|
| Problem repetition | Every story is different | A loose theme appears | The same painful event repeats |
| Recent behaviour | Only hypothetical interest | One recent example | Several detailed recent examples |
| Existing workaround | They do nothing | Occasional manual effort | Regular time, tools or spending |
| Urgency | Someday would be nice | A deadline or trigger exists | They are trying to solve it now |
| Buyer access | You cannot reach the buyer | Users can introduce you | You are speaking to budget owners |
| Commitment | Compliments only | A call, data or pilot access | Money or purchasing action |
| First workflow | The product needs everything | A possible wedge exists | One paid or learning loop is clear |
0–5
Stop or reframe
The evidence does not yet justify product work. Change the customer, problem or test.
6–10
Narrow and test again
A useful pattern exists, but the buyer, urgency or commitment still needs a stronger test.
11–14
Scope the first MVP
Turn the clearest paid or learning loop into a small launch. Keep every unsupported feature outside version one.
If you can name the buyer, problem, current alternative, promised result and first workflow, you are ready for a build conversation. My fixed-scope SaaS MVP service turns that evidence into a launch-ready product in 2–3 weeks for $3,999.
Bring these answers to the scoping call
- Who is the first customer, in words that let us find ten more?
- What recent event makes the problem urgent?
- What do customers use, pay or do today instead?
- Which commitment did someone make during validation?
- What is the one complete workflow version one must deliver?
- What result will tell us whether the MVP deserves another iteration?
SaaS idea validation FAQ
- How do you validate a SaaS idea?
- Choose one customer segment, study recent examples of the problem, identify the current workaround, and run the smallest test that asks for meaningful commitment. Build only when the evidence points to one clear first workflow.
- Can I validate a SaaS idea without coding?
- Yes. Interviews, a landing-page offer, a clickable prototype, a manual concierge service and a paid pilot can test different assumptions before production software exists.
- Is a waitlist enough validation?
- A waitlist shows that the message earned a low-cost action. It does not prove the person has the problem, will use the product or will pay. Follow up with interviews and a stronger commitment test.
- How many customer interviews should I run?
- There is no universal magic number. Start with a small set from one segment and continue until stories repeat clearly enough to design the next test. Quality and specificity matter more than collecting a large mixed sample.
- Should I ask people if they would pay?
- Do not rely on a hypothetical yes. Ask what they pay or do today, who controls the budget, and whether they will take a concrete next step such as a pilot, deposit or purchasing conversation.
- When is a SaaS idea ready for an MVP?
- It is ready when you can name the first user, the recurring problem, the current alternative, the promised outcome, the path to reach buyers and one narrow workflow that produces useful evidence after launch.
Research sources
The seven-day sequence and scorecard are my working method. The interview, assumption-testing, prototyping and manual-delivery principles draw from the primary sources below, checked on August 27, 2026.
- Y Combinator: How to Talk to Users
- Rob Fitzpatrick: The Mom Test
- Strategyzer: Start With the Most Critical Hypotheses
- Strategyzer: Testing Business Ideas
- GOV.UK: Start by Learning User Needs
- GOV.UK: Making Prototypes
- Steve Blank: Value Proposition Hypotheses
- Stripe: Payment Links
- Paul Graham: Do Things that Don’t Scale
- Eric Ries: The Lean Startup Principles
- Rob Walling: Books for SaaS Founders
- Pieter Levels: The Only Real Validation Is People Paying
- April Dunford: Obviously Awesome
about the author
Api Alam
Indie maker and bootstrap founder. I build SaaS products, ship in public and help founders turn a focused scope into a working MVP.
How I build MVPs