Before building your SaaS MVP, validate the assumptions behind the customer, problem, willingness to switch, solution, MVP scope, pricing, and distribution. This framework helps founders identify the biggest risks before turning them into expensive product decisions.
A founder has an idea for a SaaS product. The customer seems obvious, the problem sounds painful, the features make sense, and competitors already exist, which appears to prove there is a market. So the founder opens Figma, starts prompting an AI coding tool, or hires a development team. Three months later, the MVP works.
There is only one problem: almost everything the product was built around was still an assumption.
The founder assumed the right customer had been chosen, that the problem happened often enough, that people cared enough to change their current workflow, that the proposed solution was better, that the selected features belonged in the MVP, that customers would pay, and that those customers could actually be reached. Development validated none of those things. It only validated that the software could be built.
An MVP should come after your biggest assumptions become clearer, not become the tool you use to discover all of them. The goal is not certainty. The goal is to make sure the next investment is based on evidence rather than founder intuition.
Here are seven assumptions worth validating first.
1. You Are Solving the Problem for the Right Customer
Most SaaS ideas begin with a customer description that is far too broad: “small businesses,” “marketing teams,” “healthcare companies,” “recruiters,” or “e-commerce brands.” Those categories may describe a market, but they do not describe a useful first customer.
Imagine you want to build software that helps recruitment agencies manage candidate follow-ups. That still leaves enormous variation. A two-person recruitment agency placing freelance developers operates very differently from a 200-person executive search firm. They have different workflows, budgets, approval processes, software stacks, and consequences when something goes wrong. An MVP built for both usually becomes bloated before it has a single customer.
Your first assumption is therefore:
We know which specific group experiences this problem strongly enough to become our first customer.
Before building, narrow the customer using characteristics that actually change the problem: industry or niche, company size, role, workflow, current tools, buying authority, business model, maturity, and the trigger that makes the problem urgent.
Instead of targeting simply “recruitment agencies,” you might begin with small technical recruitment agencies with 2–10 employees that place contractors and currently coordinate candidate follow-ups through spreadsheets, email and WhatsApp.
That is a group you can actually research. You are not committing to that niche forever. You are deciding who you need to understand first.
What would validate this assumption?
Talk to people matching the same narrow profile and look for repeated patterns. If ten conversations produce ten completely different problems, your segment may still be too broad. If the same workflow, friction and language keep appearing, you are getting closer to a useful first market.
2. The Problem Is Painful Enough to Matter
A problem can exist without creating a viable SaaS opportunity. People complain about hundreds of small inconveniences every week, but that does not mean they will buy software to remove them.
Suppose your target customer says, “Yeah, managing this spreadsheet is annoying.” That is useful information, but it is not enough. You need to understand what happens because the spreadsheet is difficult to manage. Do candidate follow-ups get missed? Do placements get delayed? Does someone spend six hours every Friday cleaning it? Does the business lose revenue? Does a manager have to manually check every row? Does the problem happen once per year or six times per day?
The stronger question is not “Does this problem exist?” It is “Does this problem create enough consequence that someone is motivated to change something?”
A founder can easily exaggerate a problem because the solution already exists in their head. Your customer has no reason to do that, which is why their current behaviour matters more than their polite reaction to your idea.
Stronger signals
The problem is more promising when customers:
- encounter it frequently
- have already created a workaround
- involve multiple employees in solving it
- lose meaningful time or money because of it
- complain about it without being prompted
- have tried existing products
- actively search for a better solution
- face business risk when it goes wrong
If the response is consistently, “It is annoying, but we manage,” that deserves attention too. Sometimes the correct validation result is not yet worth building. That is still valuable information because it prevents you from investing deeply in a low-priority problem.
3. Customers Actually Want the Problem Solved Differently
This is where many SaaS ideas become misleading. You can find a real customer and a real problem, then still be wrong about whether that customer wants your solution.
A manual workflow may look inefficient from the outside but still be acceptable to the people doing it. Consider the recruitment agency again. Their spreadsheet may be ugly, their WhatsApp threads may be chaotic, and their inbox may be overloaded, but everyone already knows how those tools work. The spreadsheet costs almost nothing, no migration is required, no team training is required, no new vendor must be approved, and no historical data must be moved.
Your SaaS is not competing only with another SaaS product. It is competing with the cost of doing nothing, and that cost is often much lower than founders expect.
Your assumption is:
The improvement we offer is significant enough for this customer to change their existing behaviour.
Ask customers what they use today, then go deeper. Why do they still use it? What works well about the current method? What frustrates them? What would make them replace it? What would make switching difficult? What data would need to move? Who else would need to agree?
A product that is 15% more convenient may not be enough. Switching usually requires something more meaningful: faster completion, fewer errors, less labour, more revenue, lower risk, or a workflow that was previously impossible. The improvement needs to be strong enough to justify the disruption.
This is why competitor research alone cannot validate your SaaS idea. Competitors show what companies have built. Customers show what people are actually willing to change.
Our earlier article on why SaaS products fail before development begins explores this distinction in more detail.
4. Your Proposed Solution Fits the Customer's Workflow
Once founders understand the problem, they often jump immediately to features: dashboards, notifications, AI assistants, automations, analytics, team management, integrations. A list of useful-sounding features does not prove the product fits into how the customer actually works.
The more useful question is:
Where does this product sit inside the customer's existing workflow?
Imagine the recruitment agency's real workflow is: lead arrives → recruiter screens candidate → candidate is added to a spreadsheet → recruiter messages them → client interview is scheduled → recruiter follows up → placement is completed.
Now suppose your product requires recruiters to manually copy information into a separate platform after every conversation. Technically, you solved the tracking problem. Operationally, you introduced another job.
Your solution should either remove enough work, combine fragmented steps, reduce risk, or create a sufficiently valuable new outcome to justify becoming part of that workflow. Before coding the full experience, test the concept using cheaper tools such as workflow diagrams, clickable prototypes, mockups, spreadsheets, no-code tools, landing pages, recorded demos, or even a manually delivered service behind a simple interface.
You are looking for reactions beyond “Looks great.” Ask where the product would fit into their current process, what they would stop using, which part their team might resist, what information would need to enter the system first, and what would have to happen before the product became useful.
A beautiful prototype that cannot fit naturally into the customer's day is still a weak product.
5. You Know What the MVP Actually Needs to Prove
An MVP is often treated as version one of everything the founder eventually wants. That usually produces a smaller product, not a useful experiment.
Suppose the long-term vision includes candidate management, automated follow-ups, client portals, reporting, AI candidate matching, billing, team permissions, integrations and analytics. The founder removes a few advanced features and calls the remaining eight features an MVP. The problem is that no one has answered the most important question: what is this MVP supposed to prove?
Maybe your biggest uncertainty is whether recruiters will trust automated follow-up reminders enough to move candidate tracking out of their spreadsheet. In that case, the MVP should focus heavily on that workflow.
Maybe the real uncertainty is whether agencies will pay to prevent candidate follow-ups from being missed. You may not even need a complete software product yet; a manually delivered pilot might teach you more.
A useful MVP has a clear hypothesis, for example:
If technical recruitment agencies can automatically see which candidates need follow-up today, they will use the product several times per week because it reduces missed candidate communication.
Now the features have a reason to exist. Every feature should help the user reach the experiment, experience the value, or help you measure what happened. Everything else can wait.
A simple MVP test
For every proposed feature, ask: If we remove this, can we still test the core assumption? If the answer is yes, that feature probably does not belong in the first version.
6. Customers Are Willing to Pay Enough for the Product
One of the most dangerous statements in early SaaS validation is, “We will figure out pricing later.” Pricing is not only a monetization decision. It is part of product validation.
A customer saying, “I would definitely use this,” means something very different from saying, “If it solves what you described, I can pay $150 per month.” Money forces prioritization. Customers may like ten different SaaS products, but they cannot necessarily buy all ten.
Ask what they already pay for and how software purchases work inside the business. What budget owns this problem? Is software purchased by the individual, team, department or company? Does the buyer need approval? Is the cost compared against software, labour, revenue leakage or something else?
If your SaaS saves a company $100 per month but needs to cost $300 per month to support the business model, better product design cannot fix that equation. Pricing conversations can also expose whether you are targeting the right customer. A problem may be severe for one segment but economically impossible to serve, while another segment may experience the same problem at a larger scale and happily pay ten times more.
Do not ask only, “Would you pay for this?” Ask what customers currently spend solving the problem, whether they have purchased software for it before, who approves the purchase, what price range requires additional approval, what outcome would make the product obviously worthwhile, and what happens financially if the problem remains unsolved.
Better still, test commitment through a paid pilot, deposit, pre-order, early access plan, or another meaningful commercial signal. Actual payment is not always possible before an MVP exists, especially in complex B2B sales, but you should move as close to real commitment as your stage allows.
7. You Know How the First Customers Will Find You
Imagine the MVP launches tomorrow. Who sees it?
Many founders spend months answering “What should we build?” and almost no time answering “How will the first 10 customers discover it?” Then launch day arrives, the product works, the website is live, the founder posts it on LinkedIn, and almost nothing happens.
Distribution was treated as something that begins after development. It should have been one of the assumptions tested beforehand.
Your assumption is:
We have at least one realistic way to repeatedly reach people matching our target customer profile.
For an early B2B SaaS, that might be founder-led outbound, LinkedIn prospecting, niche communities, industry events, partnerships, existing professional networks, targeted cold email, niche content, integration marketplaces, associations, or direct sales.
SEO, paid acquisition and broader content can become important later, but many early SaaS products first need a more direct route to customers. If you cannot identify 50 people or companies that match your ICP today, that is useful information. If you can identify them but none will talk to you, that is also useful information.
Validation and distribution should overlap. The same people you interview before development can become design partners, pilot customers, early adopters, referral sources, or launch users. This changes the launch question from “Where do we find customers?” to “Which of the people already involved in shaping this are ready to try it?” That is a much stronger position.
The 7 Assumptions in One View
Before building your SaaS MVP, write these seven statements down.
1. Customer
We believe [specific customer] is the best first segment for this product. Evidence should show repeated characteristics across the people experiencing the problem.
2. Problem
We believe [specific problem] happens frequently enough and creates a meaningful consequence. Evidence should show repeated pain, cost, workarounds or urgency.
3. Change
We believe customers have enough motivation to replace or modify their current workflow. Evidence should show dissatisfaction strong enough to overcome switching friction.
4. Solution
We believe our proposed approach fits naturally enough into the customer's workflow to improve it. Evidence should come from prototypes, workflow testing or manually delivered versions of the solution.
5. MVP
We believe the first product only needs [core workflow] to test [specific hypothesis]. Everything included should support that experiment.
6. Pricing
We believe the customer can and will pay approximately [price/range] for this outcome. Evidence should move beyond compliments toward commercial commitment.
7. Distribution
We believe we can repeatedly reach these customers through [specific channel]. You should know where the first customers are likely to come from before launch.
Do Not Try to "Fully Validate" Everything
There is an important trap here: you can spend too long researching too. Ten more interviews become twenty, twenty become fifty, then another survey, another competitor analysis, and another market report. Eventually validation becomes a way to avoid making a decision.
The purpose is not certainty. Startups do not get certainty. The purpose is to reduce the most expensive uncertainty before you convert it into product development.
Some assumptions can be tested through conversations. Others need prototypes. Some require a real product, and some only become clear after customers use the software for several months. Your job is to test each assumption using the cheapest credible evidence available at that stage.
That next investment might be another week of customer research, a prototype, a paid pilot, or finally the MVP.
A Practical Validation Scorecard
Before approving development, score every assumption from 0 to 3.
0 — Belief: The assumption exists mostly because the founders believe it.
1 — Conversation: Customers have discussed the issue, but there is little behavioural evidence.
2 — Behaviour: You have observed repeated workflows, workarounds, spending, usage or other meaningful behaviour supporting the assumption.
3 — Commitment: Customers have taken an action that costs something: time, data, reputation, money or operational effort.
For example:
| Assumption | Score |
|---|---|
| Customer segment | 2 |
| Problem severity | 3 |
| Willingness to change | 2 |
| Solution fit | 1 |
| MVP hypothesis | 2 |
| Willingness to pay | 0 |
| Distribution | 1 |
You do not need 3/3 everywhere before touching code. The scorecard simply shows where the risk lives. In the example above, pricing is almost entirely assumed, while solution fit and distribution are also weak. Building twelve features will not strengthen those assumptions. The founder should probably test those areas first.
What Should You Have Before Building?
You do not need a 70-page business plan. You need enough clarity that your design and engineering decisions are based on something stronger than founder intuition.
Before committing serious budget to your SaaS MVP, aim to have:
- one clearly defined initial customer segment
- a specific problem supported by repeated customer evidence
- a clear understanding of the current workflow and alternatives
- evidence that customers have meaningful motivation to change
- a proposed solution tested at least conceptually
- one clearly defined MVP hypothesis
- a rough pricing and buying model
- a realistic path to the first customers
- a defined path from sign-up to first meaningful value
If several of these are still completely unknown, development is probably premature. That does not mean the idea is bad. It means you still have cheaper ways to learn.
What If You Have Already Started Building?
Do not throw everything away. Instead, separate what has been built from what has been validated, then score the same seven assumptions honestly.
You may discover that the architecture is fine but the ICP is unclear, that customers genuinely have the problem but the MVP contains far too many workflows, that people use the product but will not pay enough for the economics to work, or that the product solves something valuable but customers take too long to experience it. Those are different problems, and they should be treated differently.
If the product has already become difficult to operate or change safely, the challenge has moved beyond validation. Our guide on how to rescue a SaaS product you don't trust covers how to decide what should be kept, repaired, replaced or retired.
If you have already used AI to build a working prototype, validation is only one side of launch readiness. How to audit an AI-built product before launch covers the product, security, reliability and operational checks that come next.
Frequently Asked Questions
What should I validate before building a SaaS MVP?
At minimum, validate your initial customer segment, the severity of the problem, willingness to change from the current workflow, solution direction, MVP hypothesis, willingness to pay and a realistic customer acquisition channel. You do not need absolute proof of every assumption; you need enough evidence to understand where the largest risks remain before spending heavily on development.
How do I validate a SaaS idea without building the product?
Use customer interviews, workflow observation, landing pages, mockups, clickable prototypes, spreadsheets, no-code tools, manual services and paid pilots. Choose the cheapest method capable of testing the assumption you care about. If you are testing whether customers experience the problem, you probably do not need software. If you are testing whether the interaction itself works, a prototype may be necessary.
How many customers should I interview before building an MVP?
There is no universal number. Interview enough people within the same narrow customer segment to identify repeated patterns in their problems, workflows, current solutions, buying behaviour and language. Ten relevant conversations can produce better evidence than fifty conversations with loosely related customers.
Does having competitors validate my SaaS idea?
Competitors are evidence that companies believe the market is worth pursuing, but they do not automatically validate your specific customer, positioning, workflow or solution. You still need to understand why customers choose an alternative, why they leave it, what they use instead and why they would switch to you.
Should I ask customers whether they would use my SaaS?
You can, but do not rely heavily on hypothetical answers. Questions about past behaviour are usually stronger. Ask when the problem last occurred, what they did, what it cost, which tools they used, what they have already tried and whether they have paid to solve it. Behaviour creates stronger evidence than polite enthusiasm.
Should I validate pricing before developing the MVP?
Yes, at least at a hypothesis level. You should understand who pays, what budget the purchase comes from, what alternatives currently cost and what outcome makes the product financially worthwhile. Whenever possible, move beyond hypothetical pricing conversations toward a paid pilot, deposit, pre-order or another meaningful commitment.
When is a SaaS idea validated enough to build?
When you have enough evidence that a specific customer repeatedly experiences a meaningful problem, has motivation to change, sees value in your proposed direction, can realistically be reached and has a plausible willingness to pay. There will still be uncertainty. The goal is not to eliminate it; the goal is to ensure the next major investment tests the remaining uncertainty rather than blindly adding features.
Build After the Questions Get Smaller
Your SaaS idea begins as a collection of beliefs. That is normal. The problem begins when those beliefs quietly turn into requirements: “Users need team management.” “Customers will pay $99.” “Our target market is small businesses.” “We need an AI assistant.” Each statement sounds concrete, but without evidence it is still an assumption.
Every untested belief that enters development becomes more expensive to challenge later. A sentence becomes a wireframe, the wireframe becomes code, and the code becomes infrastructure. Eventually the team becomes reluctant to remove something because three months have already been spent building it.
Validation reverses that sequence:
Assumption → evidence → decision → scope → development.
Not every assumption will survive, and that is the point. Finding out that something is wrong during a customer interview can cost an afternoon. Finding out after launch can cost the entire MVP.
SaaSloom's SaaS MVP Plan is designed for this stage. We validate the customer, problem and core assumptions, define the MVP scope and core workflows, and turn the findings into a product roadmap before development begins.
