How to Validate a SaaS Idea Before You Build
A polished dashboard, Stripe billing and a carefully planned feature set can still fail if nobody needs the product. Learning how to validate a SaaS idea means finding evidence that a specific group of people has a painful problem, is actively looking for a better way to solve it, and may pay for your approach.
That evidence should come before the full build. It saves months of development, reduces expensive changes later, and gives you a much clearer brief for design, architecture and launch.
Start with a narrow problem, not a broad product
Most weak SaaS ideas begin with a category: “software for tradespeople”, “an AI tool for agencies”, or “a better CRM for small businesses”. Categories are markets, not problems. They are too broad to validate and even harder to build for well.
A stronger starting point is a repeated, costly workflow problem. For example, an agency owner may spend several hours each week pulling project updates from email, spreadsheets and client calls. A property manager may chase documents across WhatsApp and shared folders. A compliance team may manually check the same data in several systems before approving a request.
Write the problem in one sentence: “People who do X struggle to achieve Y because Z.” Keep it specific enough that someone can recognise themselves in it. If you cannot describe the user, their current process and the cost of that process, you are still at the idea stage.
Cost does not always mean money. It can be wasted staff time, missed leads, slow client onboarding, mistakes, compliance risk or a poor customer experience. The best SaaS opportunities usually sit close to a measurable business outcome.
Speak to people who already feel the pain
Customer conversations are the fastest route to useful validation, but only if you ask about what people do now. Avoid leading with your proposed product. If you ask, “Would you use an automated client portal?”, many people will politely say yes. That is not a buying signal.
Instead, ask them to describe the last time the problem happened. What triggered it? How did they deal with it? Which tools were involved? How long did it take? What went wrong? Have they paid for a workaround, hired someone to handle it, or built their own spreadsheet or internal tool?
Past behaviour is more reliable than future promises. Someone who has spent £300 a month on an existing tool, or loses a day every week to manual admin, is far more interesting than someone who simply thinks the idea sounds useful.
Aim for 10 to 15 conversations with people who match a defined customer profile. For a B2B SaaS product, speak to the person who feels the problem and the person who controls the budget. They may be the same person in a small business, but not in a larger company.
You are listening for patterns, not collecting compliments. If several people describe the same workflow in similar language, use that language in your positioning. It will make your landing page, sales calls and product UI much more precise.
Questions that reveal real demand
Useful questions include:
- “Talk me through how you handle this today.”
- “What happens when that process goes wrong?”
- “What have you tried already?”
- “How much time or money does this cost each month?”
- “Who would need to approve a new tool?”
- “What would make changing your current process worthwhile?”
Do not treat every objection as a request for another feature. Sometimes it reveals that the buyer is wrong, the timing is poor, or the existing process is good enough. Those are valuable findings too.
Check whether the market already pays
Competition is not proof that your idea is unoriginal. It is often proof that customers understand the problem and allocate budget to solve it. The key question is whether there is room for a sharper offer.
Review competing products, but also look at indirect alternatives. Your real competitor may be a spreadsheet, a virtual assistant, a shared inbox, a generic project management tool or a clumsy internal process that people tolerate because switching feels risky.
Look for gaps in audience, workflow or delivery. A large platform may be too complex for a small service business. A well-known product may work globally but miss UK-specific requirements. An existing tool may cover the main process but make one critical step painfully manual.
Do not assume you need to beat established software feature for feature. Early SaaS products win by solving one valuable job more clearly, more quickly or with less setup. A focused client approval tool can be more compelling than a broad project management platform if it removes a genuine bottleneck.
Test the proposition before building the app
Once you have a clear problem and repeated interview evidence, test whether people respond to your proposed solution. A simple landing page is often enough at this stage.
Explain who the product is for, the problem it removes, the outcome it creates and how it works at a high level. Use plain language. “Turn messy client requests into approved work in one place” is stronger than “An intelligent workflow platform for modern teams.”
Add a direct call to action that asks for a meaningful commitment. Depending on the product, that could be booking a discovery call, joining a paid pilot, requesting early access, or placing a refundable deposit. An email address is useful, but it is a weak signal on its own. A calendar booking or payment is much harder to fake.
Send targeted traffic rather than relying on general social posts. Contact people you interviewed, share the page in relevant professional communities where permitted, run a small paid campaign, or use direct outreach to a tightly defined list. The aim is not high visitor numbers. You need feedback from the right people.
Track the full path: visits, call bookings, replies, pilot commitments and payments. If people visit but do not act, the issue may be the message, the audience or the level of urgency. Follow up with those who showed interest and ask what stopped them taking the next step.
Sell a pilot, not a finished promise
For many B2B ideas, the strongest validation is a paid pilot with a real customer. This does not require a fully finished platform. It requires an honest scope, a clear outcome and enough of the workflow working to deliver value.
You might combine a lightweight web interface with manual operations behind the scenes. For example, a reporting product could collect data through a basic upload flow while you prepare early reports manually. An automation tool could use existing APIs and a simple dashboard before advanced rules, team permissions and polished analytics are built.
This approach is sometimes called a concierge MVP. The customer sees the outcome they are paying for, while you learn which parts genuinely need automation. It is especially useful where integrations, browser extensions, document workflows or bespoke business rules are involved.
Be transparent about the pilot. Tell customers what is live, what is being tested, what support they can expect and how their feedback will influence the product. A good early adopter will tolerate rough edges if the problem is significant and the value is clear.
Payment matters because it tests priority. Free users may be interested, but paid users have decided the problem is worth solving now. Even a modest pilot fee can separate curiosity from demand.
Decide what evidence is enough
There is no universal number of interviews, sign-ups or pre-orders that guarantees success. A £20-per-month self-service tool needs more volume than a £1,000-per-month B2B workflow product. A product for a niche professional audience may validate with a handful of committed pilots, while a consumer app may need hundreds of active users to show a pattern.
Set your validation criteria before interpreting the results. For example, you may decide to proceed only if at least five target customers confirm the same pain point, three agree to a pilot conversation, and one is willing to pay for an early version. The exact threshold depends on your price point, sales cycle and build cost.
Also decide what would make you stop or change direction. Perhaps customers care about the problem but not enough to switch tools. Perhaps they want a service rather than software. Perhaps the best opportunity is a browser extension that fits into an existing system, rather than a standalone SaaS platform.
Changing direction is not failure. It is the point of validation. It is far cheaper to adjust a landing page, pilot scope or product position than to rebuild a production app after launch.
Build only the workflow that earns its place
Once people are paying or actively committing, turn the evidence into a focused first release. Prioritise the core job the product must complete. Authentication, billing, data handling, key integrations and support tools may be necessary foundations, but avoid adding every requested feature before the workflow is proven.
A production-grade SaaS product still needs care around permissions, error states, backups, analytics, performance and deployment. But the right technical foundation should support learning, not delay it. A well-planned build can use tools such as Stripe for subscriptions, Supabase for authentication and data, and relevant APIs for automation without over-engineering the first version.
Keep speaking to early customers after launch. Watch where they hesitate, what they ignore and which manual steps remain. Product analytics can show what happened; a short call often explains why.
The goal is not to prove that your original idea was right. It is to earn the confidence to build the next piece with real customer evidence behind it. A smaller product that solves one expensive problem well is a far better starting point than a feature-rich platform searching for a reason to exist.