How to Validate Your SaaS Idea Before Writing a Single Line of Code

Most SaaS Products Fail Because They Skip Validation

The graveyard of failed SaaS products is not filled with bad ideas executed poorly. It is filled with reasonable ideas that nobody validated before spending six months and £100,000 building them. The founder had a problem. The founder assumed others shared the problem. The founder built a solution. The solution launched to silence. This pattern repeats thousands of times a year, and it is almost entirely preventable.

As a SaaS development agency, we see this pattern from the other side. Founders come to us ready to build. They have wireframes, feature lists, sometimes even detailed Figma designs. What they often do not have is evidence that anyone will pay for what they want to build. We have learned — sometimes by watching clients succeed and sometimes by watching them struggle — that the validation work done before development begins is the single strongest predictor of whether a SaaS product will find its market.

Here is the six-step validation framework we recommend to every founder before we write a single line of code.

Step 1: Problem Interviews — Confirm the Pain Is Real

Your first job is not to pitch your solution. It is to confirm that the problem you want to solve actually exists, that real people experience it, and that it bothers them enough to pay for a solution. Problem interviews are the fastest, cheapest way to do this.

How to Run Them

Talk to fifteen to twenty people in your target market. Not friends. Not family. Not people who will be polite. Find people through LinkedIn, industry forums, Reddit communities, or existing professional networks. Ask them about their workflow, their frustrations, and how they currently handle the problem you are interested in solving.

Questions That Work

• "Walk me through how you currently handle [the problem area]. What does a typical week look like?"
• "What is the most frustrating part of that process?"
• "Have you tried to solve this before? What did you try? Why did it not work?"
• "If you could wave a magic wand and fix one thing about this process, what would it be?"
• "How much time or money does this problem cost you each month?"

What You Are Looking For

Consistent patterns across interviews. If twelve out of fifteen people describe the same frustration unprompted, you have a real problem. If the frustration is scattered — everyone mentions something different — the problem may not be focused enough to build a product around. Pay special attention to the workarounds people have built: spreadsheets, manual processes, cobbled-together tool combinations. Workarounds are evidence that the pain is real enough to invest effort in solving, but the existing solutions are inadequate.

Red Flag

If people say "yeah, that would be nice" but cannot describe the problem in their own words or quantify its cost, the pain is not severe enough to drive purchasing behaviour. Nice-to-have problems produce nice-to-have products that nobody pays for.

Step 2: Competitor Analysis — Understand the Landscape

If nobody else is solving the problem, that is not necessarily good news. It might mean the market is too small, the problem is too niche, or previous attempts failed for reasons you have not discovered yet. Competitors validate demand. The absence of competitors should make you cautious, not excited.

What to Analyse

• Direct competitors: Products that solve the same problem for the same audience. Study their pricing, positioning, feature sets, and customer reviews.
• Indirect competitors: Products that solve adjacent problems or the same problem for a different audience. These often indicate market direction.
• Substitute solutions: Spreadsheets, manual processes, agencies, freelancers — the non-software alternatives your target customers currently use.

Key Questions

Where are competitors weak? Read their one-star and two-star reviews on G2, Capterra, and Trustpilot. The complaints tell you exactly where the market is underserved. What do competitors charge? This tells you what the market has established as the acceptable price range. How do competitors position themselves? The gaps in their positioning are potential entry points for you.

Red Flag

If a well-funded competitor already dominates the space and has high customer satisfaction, entering with a marginally better product is unlikely to succeed. You need a fundamentally different angle — a different audience segment, a different pricing model, or a different product philosophy.

Step 3: Pricing Validation — Confirm Willingness to Pay

This is the step most founders skip, and it is the most important. A problem can be real, a solution can be elegant, and the product can still fail because the target market will not pay enough to make the business viable.

The Van Westendorp Method

Ask your interview subjects four pricing questions about your proposed solution (describe the concept, do not show a product):

• "At what price would you consider this too expensive to even consider?"
• "At what price would you start to think it is getting expensive but might still consider it?"
• "At what price would you consider it a good deal — good value for money?"
• "At what price would you think it is so cheap that you would question its quality?"

Plot the responses and you get a clear acceptable price range. If the range is too low to sustain a business (factoring in customer acquisition costs, infrastructure, support, and your own salary), the idea is not commercially viable at its current scope — even if the problem is real.

Red Flag

If the majority of respondents say they would use it "if it were free" but the acceptable paid range is below £20/month, you likely have a feature, not a product. Consider whether this would be better as a feature within an existing platform rather than a standalone SaaS.

Step 4: Landing Page Test — Measure Real Interest

Interviews tell you what people say they would do. A landing page test tells you what they actually do when presented with an opportunity to act. Build a single-page website that describes your product as if it already exists. Include a clear value proposition, three to five key benefits, a pricing indication, and a call to action — either "Join the waitlist" or "Request early access."

How to Execute

Build the page in a weekend using any landing page tool or a simple HTML template. Drive traffic through targeted ads — £500 to £1,000 in Google Ads or LinkedIn Ads targeting your exact audience is sufficient. Measure the conversion rate: what percentage of visitors enter their email?

Benchmarks

A landing page conversion rate above 5% for a waitlist signup is a strong signal. Between 2% and 5% is encouraging but not definitive. Below 2% suggests either the positioning is wrong (experiment with different messaging) or the demand is weak. If you collect one hundred or more email addresses, you also have a launch audience — people who have explicitly opted in to hear about your product.

Red Flag

If you spend £1,000 on well-targeted ads and get fewer than ten email signups, the market is telling you something. Either the problem is not urgent enough to drive action, or your positioning does not communicate the value clearly enough. Test different messaging before concluding the idea is dead.

Step 5: Concierge MVP — Deliver the Value Manually

Before building any software, deliver the core value of your product manually. If your SaaS will automate competitor price monitoring, do it manually for five clients using spreadsheets and email. If your SaaS will generate weekly reports, write those reports by hand for five customers. If your SaaS will match freelancers with projects, do the matching yourself through conversations.

Why This Works

A concierge MVP answers the most important question in SaaS: will people pay for this outcome? Not for the software — for the outcome. If five customers will pay you £200/month to receive weekly competitor price reports that you compile manually, they will almost certainly pay £99/month for software that does it automatically. You have validated demand for the outcome, which is far more valuable than demand for the technology.

What You Learn

Manual delivery forces you to understand the actual workflow in detail. You discover edge cases that never appeared in interviews. You learn which parts of the process customers care about most and which they barely notice. This knowledge directly informs your MVP feature prioritisation — build the parts customers value most, defer the parts they do not care about.

Red Flag

If you offer to deliver the value manually for free and people still do not engage, the problem is not urgent enough to sustain a product. Move on.

Step 6: Smoke Test — Pre-Sell Before You Build

The ultimate validation is a transaction. Before you write code, try to get customers to commit money — either a pre-purchase, a deposit for early access, or an annual subscription paid upfront at a significant discount.

How to Execute

Take your waitlist (from step four) and your concierge clients (from step five) and offer them founding member pricing: a 40-50% lifetime discount in exchange for paying upfront and providing feedback during development. Use a simple payment page through Stripe — no product required yet, just a clear description of what they are buying and when they will receive it.

The Magic Number

If you can get ten paying customers before writing code, you have strong validation. You have revenue, a feedback group, and the psychological commitment that turns early users into advocates. If you cannot get anyone to pay, even at a significant discount, that is the clearest possible signal that the market does not want this enough to exchange money for it.

Common Validation Mistakes

• Validating with the wrong audience: Asking developers whether a marketing tool is useful gives you developer opinions, not marketer buying decisions. Validate with the people who would actually purchase and use the product.
• Treating positive feedback as validation: People are polite. "That sounds great!" is not validation. An email signup, a pre-payment, or a detailed description of how they would use it daily — those are validation.
• Spending too long validating: Validation should take four to eight weeks, not six months. If you cannot find evidence of demand in two months of focused effort, more time is unlikely to change the outcome.
• Validating the technology instead of the outcome: "Would you use an AI-powered platform that..." leads people to evaluate the technology. "Would you pay for a service that saves you ten hours per week on..." leads them to evaluate the outcome. Validate outcomes, not implementations.

When to Stop Validating and Start Building

You are ready to build when you have:

• Fifteen or more problem interviews confirming a consistent, quantifiable pain point
• Competitor analysis showing a clear gap or underserved segment
• Pricing validation showing willingness to pay at a level that sustains a business
• A landing page with a conversion rate above 3%
• At least three concierge clients who have experienced the value and confirmed they would pay for a software version
• Ideally, pre-sales or deposits from founding customers

You do not need all six — but you need at least four of them to be strongly positive. If three or more are weak, revisit your positioning, audience, or the idea itself before investing in development.

If you have validated your SaaS idea and are ready to discuss what building it looks like, book a free strategy session. We will review your validation data, help you define the minimum viable scope, and give you a realistic timeline and budget for your first release.