Validation in the SaaS context means gathering evidence that a specific group of organisations or people has a problem they will pay to solve, before you commit development budget. It is not about proving that an idea sounds clever or that a market category exists. It is about demonstrating that the problem is real, frequent, and painful enough to justify a subscription.

Many founders confuse interest with intent. Someone saying "that's a good idea" in conversation does not tell you whether they would open their organisation's procurement process, hand over payment details, or change an established workflow. Validation has to close that gap.

For SaaS specifically, the stakes are higher than with one-off software projects. A SaaS product carries ongoing infrastructure costs, support obligations, and a business model that only works if enough customers stay subscribed long enough to cover acquisition and delivery costs. Building without validation means committing to that operating model on a guess.

Plan the work around these checkpoints

What a validated idea looks like

A validated idea typically shows several things: you can name the exact role or job title of the person who feels the pain; you can describe the current workaround they use; you have evidence, not assumptions, about how often the problem occurs; and you have a signal — not necessarily a signed contract, but something firmer than polite encouragement — that they would pay for a solution.

Validation does not require a working product. In fact, building a product to validate an idea is often the most expensive and slowest way to do it. The point is to learn whether the product is worth building at all.

Where validation fits in the process

Validation sits between having an initial idea and defining what goes into a minimum viable product. It answers the question "should we build this?" The next question — "what should we build first?" — is a separate scoping exercise. Keeping these two stages distinct prevents you from jumping to feature lists before you have confirmed the problem is worth solving.

Problem interviews

Talking to potential users is the most direct form of validation, but only if the conversations are structured around their current behaviour, not your proposed solution. Ask what they do today, how much time or money the current approach costs them, what they have already tried, and what stopped those attempts from working. Avoid presenting your idea and asking for approval. People are generally polite and will tell you your idea sounds good even if they would never use it.

A practical sign of a real problem: the person has already spent money or time trying to fix it. If nobody has tried anything — not even a spreadsheet, not even a manual workaround — the problem may not be painful enough to sustain a SaaS subscription.

Landing page and waitlist tests

Putting up a page that describes the problem and the proposed solution, with a clear call to action such as "join the waitlist" or "request early access," can gauge whether the idea resonates with people who are actually looking for a solution rather than people you have cornered at a networking event. The key metric is not page views but the conversion rate from visitor to sign-up, and the quality of those sign-ups — are they the right job titles, in the right type of organisation?

This approach works best when you have a way to reach the target audience, such as through existing professional networks, industry forums, or targeted advertising. Without traffic from the right people, the test tells you nothing.

Pre-sales and letters of intent

In B2B SaaS, the strongest validation signal is an organisation saying, in writing, that they will buy the product once it exists, ideally with some form of commitment such as a pre-payment or a signed letter of intent. This is rare for early-stage ideas but not impossible, particularly when the founder already has relationships with potential customers through prior work or industry experience.

Even a conditional commitment — "we would trial this at £X per month if it does Y" — gives you something concrete to work with when you move to scope definition.

Competitor and substitute analysis

If several companies already offer a similar product, that is not automatically bad news. It suggests the problem is real and people are willing to pay. The validation question then shifts to whether you can serve a segment those competitors miss, or solve the problem in a way that is meaningfully better for a specific group of users.

If no competitors exist, that can be a warning sign rather than an opportunity. It may mean nobody has thought of it — or it may mean many people have thought of it and discovered there is no paying market. Look for substitutes: are people solving the same problem with spreadsheets, email chains, generic project-management tools, or manual processes? If yes, the problem exists; the question is whether a dedicated tool would be adopted.

Internal tools as a validation path

Some SaaS products start as internal tools built to solve a problem the founding team experiences directly. In this scenario, the business is its own first customer, and validation is partly built in — you know the problem is real because you live with it. The risk shifts to whether other organisations have the same problem in the same way, and whether they would adopt a solution designed around your internal context.

Integration-dependent ideas

Some SaaS ideas only work if they can connect to existing systems — accounting software, CRM platforms, or industry-specific databases. Validation in these cases should include a technical check: does the integration actually exist, is it documented, are there rate limits or costs that would make the business model unworkable? A great idea that depends on an API that does not exist or is prohibitively expensive to use is not a validated idea.

SaaS decision risks and checks

Asking friends, family or colleagues

People who want you to succeed will give you positive feedback regardless of the merit of the idea. They are also unlikely to be representative of your target customer. Validation requires speaking to people who have the problem, have the authority to buy a solution, and have no personal stake in your success.

Validating the solution instead of the problem

It is tempting to describe your proposed product in detail and ask people whether they would use it. This tests your ability to pitch, not whether the problem exists. Focus the conversation on the problem and the person's current behaviour. If they describe a workaround that costs them time or money, the problem is validated. You can then test whether your specific approach to solving it resonates, but that comes second.

Confusing survey responses with demand

Surveys can supplement validation but are dangerous as the primary method. Respondents often say they would pay for things they would not actually buy, because there is no real commitment involved. A survey result saying "80% of respondents said they would use this" means very little without behavioural evidence to back it up.

Ignoring frequency and urgency

A problem that happens once a year may be severe when it happens, but it is a poor fit for a SaaS subscription, which depends on ongoing usage and perceived value. Validation should establish not just that the problem hurts, but that it hurts often enough to justify a recurring payment.

Assuming your own experience is universal

Founders who have experienced a problem personally often assume that every similar organisation has the same problem in the same way. Your experience is a useful starting point for forming a hypothesis, but it is not evidence. You still need to test whether other organisations, with different processes, team structures, and priorities, experience the problem the same way.

Stopping validation too early

There is a temptation to treat the first few positive conversations as proof and move straight to building. A small number of positive signals can be misleading. Validation should continue until you have a pattern — multiple people, independently, describing the same problem in similar terms, without prompting.

Key checks before moving to scope definition

  • Problem clarity: Can you describe the problem in one sentence, in the language a potential customer would use, without mentioning your product?
  • Target role: Can you name the specific job title of the person who feels this problem most acutely?
  • Current behaviour: Can you describe what they do today to cope with the problem, and what it costs them?
  • Frequency: Does the problem occur often enough to justify a subscription?
  • Willingness to pay: Do you have at least one signal — a pre-sale, a letter of intent, a waitlist sign-up from a qualified prospect, or clear evidence of existing spend on workarounds — that suggests people will pay?
  • Reachability: Can you actually get in front of enough of these people to build a viable customer base?
  • Technical feasibility: For integration-dependent ideas, have you confirmed that the necessary APIs or data sources are accessible and affordable?

Validation does not guarantee success. It reduces the risk of building something nobody wants, which is the most common and most expensive way SaaS projects fail. Once you have these signals, the next step is deciding what to build first — a separate exercise in scoping a minimum viable product that tests your solution with real users, not just your problem hypothesis with conversations.