How to Validate a SaaS Idea Before Writing Any Code

A SaaS idea is not validated because people say it sounds useful.

It is not validated because a competitor raised funding, because a Reddit thread has hundreds of comments, or because a landing page collected a few email addresses.

Validation means reducing the biggest uncertainties around the business before you commit significant time and money to development.

Before writing production code, you want evidence for four things:

the problem is real, the customer is specific, the proposed solution is compelling enough to change behaviour, and someone is willing to make a meaningful commitment to get it.

That distinction matters because early SaaS teams often start with the part they can control: building.

They select a stack, design dashboards, create authentication, define subscription tiers and plan dozens of features. Months later, they discover that the real problem was slightly different, the buyer was not who they expected, or the pain was not important enough to justify another monthly subscription.

Validation reverses that sequence.

You test assumptions first.

Then you decide what deserves to be built.

Strategyzer makes a useful distinction between customer opinions and evidence. Asking someone whether they like an idea produces an opinion. Asking what they did the last time they experienced the problem produces evidence about actual behaviour. That difference should shape almost every validation activity you run. Strategyzer

The goal is not to eliminate uncertainty completely. No research process can guarantee a successful SaaS product.

The goal is to avoid spending six months solving the wrong problem.

Start with a problem hypothesis, not a product description

A weak SaaS idea usually begins like this:

"We want to build an AI-powered platform for agencies."

That tells you almost nothing.

Who inside the agency has the problem?

What are they doing today?

Why is the current process painful?

How frequently does the problem occur?

What happens if they do nothing?

A useful problem hypothesis is more specific:

"Small performance marketing agencies spend several hours each week collecting campaign data from multiple platforms and manually assembling client reports. The process is repetitive, error-prone and difficult to scale."

Now you have something you can investigate.

Before interviewing anyone, write down a few assumptions:

Customer: Who experiences the problem?

Trigger: When does the problem become important?

Current behaviour: What do they do today?

Consequence: What does the problem cost in time, money, delay, risk or lost opportunities?

Buyer: Who can actually approve a purchase?

Solution hypothesis: What change do you think would improve the workflow?

Commercial hypothesis: Why would a customer pay rather than continue with the current workaround?

Treat these as hypotheses, not facts.

Recent SaaS validation frameworks increasingly recommend explicitly writing conditions that would disprove your assumptions. This helps prevent a common founder behaviour: interpreting every conversation as confirmation that the idea is working. Codivox

For example:

"We believe agencies would pay for automated reporting."

A falsification condition might be:

"If most relevant agencies already solve this cheaply with existing tools and do not consider the remaining manual work important, our current problem hypothesis is weak."

That is much more useful than simply looking for positive feedback.

Define a narrow customer before researching the market

"Small businesses" is not a useful target market.

Neither is:

"Marketers."

"B2B companies."

"Healthcare."

The narrower your initial customer definition, the easier validation becomes.

Compare:

Broad: Accounting firms.

Better: Small accounting firms.

Much better: UK accounting firms with 10 to 50 employees that manage recurring client document collection manually through email.

The third definition gives you:

a clearer interview pool, more relevant competitors, more meaningful language, and better insight into whether the workflow is consistent enough for software.

A narrow starting segment does not mean the final product can never expand.

It simply gives you a controlled environment for learning.

One of the biggest problems with early SaaS research is mixing different customer types.

If you interview:

freelancers, enterprise buyers, small agencies and corporate teams,

you may receive four completely different answers and mistakenly conclude that the market is confusing.

The issue may simply be that you have combined four markets.

Talk to potential customers before showing them your solution

Customer interviews are one of the cheapest validation methods available.

They are also easy to do badly.

The biggest mistake is asking questions such as:

"Would you use an app that did this?"

"Do you like this idea?"

"Would automation help?"

"Would you pay £50 per month?"

People are often supportive in hypothetical conversations.

The answers feel encouraging but provide weak evidence.

Instead, ask about actual past behaviour.

Strategyzer specifically recommends replacing opinion-seeking questions with questions about the last time the problem occurred and what the person actually did. Strategyzer

Useful questions include:

"When did this problem last happen?"

"Walk me through what you did."

"How are you handling it today?"

"Who is involved?"

"How often does it happen?"

"What happens when the process goes wrong?"

"Have you tried to fix it before?"

"What tools are you paying for now?"

"Who would normally approve software for this?"

"What would make changing the current process difficult?"

Notice what is missing.

You are not pitching.

At this stage, you are trying to understand the existing reality.

Look for behaviour that indicates real pain

Not every inconvenience deserves software.

People complain about hundreds of things they will never pay to fix.

A stronger SaaS problem usually has observable consequences.

Look for evidence such as:

people building spreadsheets to manage the workflow, paying employees to perform repetitive work, purchasing multiple tools, hiring consultants, creating internal scripts, accepting regular delays or repeatedly complaining about the same operational bottleneck.

Existing workarounds are particularly valuable.

A messy workaround may be more encouraging than a customer saying:

"Nothing currently solves this."

Why?

Because the workaround shows that the problem is important enough for someone to spend effort solving.

If a prospect says:

"We export the data manually every Friday, combine it in Excel and have one employee spend half a day preparing the reports,"

you have learned far more than if they say:

"Yes, automated reporting sounds interesting."

Current behaviour carries cost.

Compliments do not.

Do not obsess over a magic interview count

You will see validation guides recommending 5, 10, 15, 20 or 30 interviews.

There is no universal number at which a SaaS idea becomes valid.

A highly specialised enterprise product may learn a great deal from a small number of conversations with the correct buyers.

A horizontal self-service product may require broader testing.

The more useful question is:

Are the conversations producing a coherent pattern?

If twelve customers from the same segment describe the same workflow, pain, workaround and buying trigger in similar language, confidence increases.

If thirty interviews produce completely different problems, use cases and buyers, adding another ten may not help.

Your segment or problem definition may be too broad.

Some recent SaaS validation guides suggest using roughly 10 to 20 focused conversations as an early discovery range, but they also emphasise that the quality and consistency of the evidence matter more than reaching a predetermined quota. Andrew Crossley

Record what people actually say.

Do not rely on memory.

Research competitors after you understand the problem

Founders sometimes worry that finding competitors invalidates their idea.

Usually, the opposite is true.

Competitors can demonstrate that customers already spend money in the category.

Your job is not necessarily to find a market nobody has discovered.

It is to understand:

what customers currently use, why they chose it, what they dislike, what remains manual, which customers are poorly served and why they might switch.

Review:

competitor websites, pricing pages, documentation, product demos, app marketplaces and customer reviews.

Pay particular attention to criticism.

One-star and three-star reviews can reveal:

missing workflows, poor onboarding, expensive plans, unreliable integrations, excessive complexity or products built for larger companies than the customer reviewing them.

But competitor gaps are not automatically opportunities.

If customers complain that a competitor lacks Feature X, ask:

"Would the absence of Feature X cause you to switch?"

A frequently requested feature can still have little purchasing influence.

Study alternatives, not only direct competitors

Your biggest competitor may not be another SaaS application.

It may be:

Excel, email, WhatsApp, shared documents, an employee, an agency, an internal script or simply doing nothing.

This is especially important in B2B software.

Suppose you are considering a SaaS product that automates employee onboarding.

You may compare yourself with dedicated HR platforms.

But your real competition might be:

a spreadsheet, a Google Drive folder and a checklist used by the office manager.

If that process works reasonably well, your product has to offer enough additional value to justify:

subscription cost, migration effort, training and organisational change.

You are not only competing on features.

You are competing against inertia.

Translate research into a specific value proposition

After interviews and market research, you should be able to describe:

who the product is for, what painful job they are trying to complete, what changes if your product works and why your approach is meaningfully different.

A useful structure is:

For [specific customer], we help [specific outcome] without [important current pain or limitation].

For example:

"For small paid-media agencies managing 20 to 100 client accounts, we automate recurring campaign reporting without requiring analysts to manually combine data from multiple ad platforms."

This still does not prove customers want the product.

But it gives you something precise enough to test.

Avoid describing the solution through a long feature list.

Customers rarely buy:

dashboards, AI, APIs, automations and workflows.

They buy an improvement in a situation.

Test the value proposition without building the SaaS

Once the problem looks credible, you can test whether your proposed solution creates enough interest for people to act.

A landing page is one common approach.

It can include:

the target problem, promised outcome, key workflow, relevant differentiation, pricing or pricing direction when appropriate and one clear call to action.

Possible actions include:

joining a waitlist, requesting early access, booking a demo, applying for a pilot, starting a pre-order or contacting the founder.

The page is an experiment.

It is not the beginning of your production frontend.

Keep it simple enough that changing the entire positioning tomorrow does not hurt.

Drive relevant people to it through:

direct outreach, professional communities, existing audiences, partnerships, niche forums or carefully targeted ads.

Track who responds, not only how many.

A hundred signups from unrelated users may teach you less than five qualified conversations with people who exactly match your target buyer.

Do not treat landing-page conversion as universal proof

You will find articles promising that a specific signup percentage means your SaaS is validated.

Be careful.

Landing-page conversion depends heavily on:

traffic source, audience intent, brand trust, offer, device, price, CTA friction and how narrowly the page is targeted.

A 4% conversion rate from cold advertising is not directly comparable with a 40% signup rate from your personal LinkedIn audience.

Recent validation guidance correctly warns against universal conversion thresholds and recommends interpreting page behaviour together with audience quality, test conditions and follow-up evidence. Codivox

The more useful questions are:

Who converted?

Why?

Did they respond to follow-up?

Do they match your intended customer?

Did they agree to a deeper conversation?

Did they care after you mentioned price?

A clickable prototype can test the workflow before the product exists

Some SaaS ideas are difficult to explain with a landing page alone.

A prototype can help when the main uncertainty is:

whether users understand the proposed workflow, whether the interaction actually solves the problem, or whether your approach is preferable to their current process.

This does not require production code.

A design prototype can simulate:

navigation, key actions, data entry, reports and expected outcomes.

The prototype should answer a specific question.

For example:

"Can an agency manager configure a recurring report without training?"

or:

"Does the buyer understand how automated exception handling would work?"

Do not turn the prototype into a hidden three-month design project.

Its purpose is learning.

A concierge test can be stronger than a prototype

Some products can be simulated manually.

Imagine your SaaS idea automatically analyses customer reviews and produces a weekly management summary.

Before building:

APIs, AI pipelines, authentication, billing and dashboards,

you could manually provide the outcome to three businesses.

Customers send you their reviews.

You perform the analysis manually or with existing tools.

You deliver the output in a document.

From the customer's perspective, you are testing the result of the future software.

This is often called a concierge MVP.

It can reveal:

whether customers value the output, how frequently they need it, what they actually use, what they ignore, what they request next and whether they return.

A manual service is not scalable.

That is not the point.

You are validating what should eventually become scalable.

Test pricing before development, not after launch

One of the most expensive mistakes in SaaS is delaying pricing until the product is nearly finished.

Price changes what the product needs to be.

A £20 monthly tool has different expectations from a £2,000 monthly platform.

Pricing also helps reveal whether the problem is commercially meaningful.

Strategyzer recommends treating willingness to pay as something that can be tested experimentally rather than guessed. Strategyzer

Ask about budgets and existing spending during research.

Later, present an actual offer.

For example:

"We are preparing a pilot for agencies with this problem. The pilot will cost £500 per month and include X, Y and Z. Would you like to participate?"

Now you are no longer asking:

"Would you pay?"

You are asking:

"Will you make this decision?"

That produces stronger evidence.

Understand the commitment ladder

Not every validation signal is equal.

Imagine six prospects:

One says the idea is interesting.

One joins your waitlist.

One spends an hour reviewing your prototype.

One introduces you to their operations director.

One signs a pilot agreement.

One pays a deposit.

These actions reveal very different levels of commitment.

A useful way to think about evidence is:

Opinion: "That sounds useful."

Attention: "I'll spend time discussing it."

Action: "I'll sign up or request access."

Organisational effort: "I'll involve my team."

Commercial intent: "I'll sign an agreement."

Financial commitment: "I'll pay."

The further someone moves down that ladder, the stronger the signal.

This is why a large waitlist can still represent weak validation.

Joining a list costs almost nothing.

A paid pilot costs money, internal effort and reputation.

Recent SaaS validation guidance consistently places paid pilots, deposits, preorders and commercially meaningful agreements above verbal interest because they require the buyer to give something up. Codivox

B2B SaaS requires buyer validation, not only user validation

A person can love your product and still be unable to buy it.

This happens constantly in B2B software.

The user might be:

a marketer.

The buyer might be:

the marketing director.

Procurement may be involved.

IT may need to approve security.

Finance may approve the budget.

Legal may review the contract.

During validation, determine:

who experiences the problem, who benefits, who controls the budget, who can block the purchase and what evidence the organisation needs before adopting a new vendor.

A product that users love but organisations cannot buy has a go-to-market problem.

You want to discover that before building the enterprise edition.

Test acquisition while you test demand

A SaaS idea can solve a real problem and still become a poor business if customers are extremely difficult to reach.

Validation should therefore include:

Can we repeatedly find the people who have this problem?

Possible channels include:

search, outbound sales, partnerships, professional communities, marketplaces, content, events or paid advertising.

You are not trying to perfect customer acquisition economics before launch.

You are looking for evidence that there is a practical route to the market.

Suppose interviews reveal excellent demand among a niche professional audience.

But that audience:

has no active communities, rarely searches for the problem, uses no central marketplace and can only be reached through expensive enterprise sales.

That does not invalidate the idea.

But it changes:

pricing, sales model and product economics.

Validation should uncover that.

Keep a validation scorecard

Founders naturally remember supportive conversations.

A scorecard reduces that bias.

After each interview or test, record evidence against consistent criteria.

For example:

Problem experienced recently: Yes / No

Frequency meaningful: Strong / Moderate / Weak

Current workaround exists: Yes / No

Current workaround costs money or time: Yes / No

Buyer identified: Yes / No

Existing budget: Yes / Unclear / No

Follow-up requested: Yes / No

Price accepted: Yes / Hesitation / Rejected

Commercial commitment: None / Meeting / LOI / Paid

Do not combine everything into an artificial mathematical score unless the score has a real decision purpose.

The value is consistency.

After fifteen conversations, patterns become much easier to see.

Decide your validation criteria before running the experiment

Suppose you publish a landing page.

You receive 27 signups.

Is that good?

Without a predefined expectation, you can tell yourself whatever you want.

Before each experiment, write:

the assumption, the test, the audience, the evidence you will collect, what result increases confidence and what result decreases confidence.

For example:

Assumption: Agency owners have enough pain around weekly client reporting to explore a paid solution.

Test: Show a reporting automation offer to 20 agency owners who match the target profile.

Strong signal: Several request a pilot after pricing is explained.

Weak signal: People say the product sounds useful but decline follow-up once the commercial model is discussed.

Now the experiment can actually change your decision.

Negative evidence is valuable

Validation is not a contest where every test must succeed.

Discovering that your idea is weak before development is a successful validation outcome.

Suppose interviews reveal:

the problem only happens twice per year, customers already solve it cheaply, the person experiencing it cannot influence purchasing, your proposed workflow adds more work than the current process or prospects like the concept until they see the price.

Those are valuable discoveries.

You can:

change the customer, change the problem, change the business model, redesign the solution or stop.

Stopping a weak idea before development is often more valuable than launching it.

Do not endlessly validate because you are afraid to build

There is an opposite failure mode.

Some founders remain in customer discovery indefinitely.

More interviews.

More surveys.

Another landing page.

Another prototype.

Another pricing conversation.

Eventually the remaining uncertainty cannot be answered without a functioning product.

You should start building when:

you have credible evidence for the customer and problem, prospects demonstrate meaningful interest in the solution direction, the buying process is understood, willingness to pay has some support, and the largest remaining questions require actual product usage.

The first build should then be designed to answer those remaining questions.

It should not be permission to implement the entire roadmap.

If you build, build the smallest version that answers the next question

An MVP should not mean:

"Version one of the entire company vision."

It should mean:

the smallest working product capable of testing the most important remaining uncertainty.

Imagine validation confirms:

accounting firms have a painful document collection problem, buyers are willing to pay and customers respond strongly to automated reminders.

The first product may only need:

client records, document requests, reminder automation and completion tracking.

You may not need:

advanced analytics, AI categorisation, mobile apps, custom branding, twenty integrations or complex team permissions.

Those features may eventually matter.

But validation has already told you what creates the initial value.

Build that first.

Common SaaS validation mistakes

Asking friends whether the idea is good

Friends are usually trying to help you.

That makes them poor substitutes for target customers.

Pitching during problem interviews

Once you explain your idea, the conversation changes.

People start evaluating your solution instead of describing their actual behaviour.

Treating surveys as customer discovery

Surveys can be useful later.

They are poor replacements for observing detailed workflows during early discovery.

Treating competition as a reason to stop

Competition can confirm that budget and demand already exist.

The question is whether you have a credible reason customers would choose your approach.

Treating no competition as proof of originality

Sometimes there is no competition because nobody wants the product.

Building a prototype that is too polished

A prototype should answer a question.

Every extra screen delays learning.

Hiding the price

If you plan to charge customers, eventually the validation process must encounter price.

Interest that disappears at pricing is useful information.

Using only waitlist size as proof

Waitlists measure interest.

They do not automatically prove willingness to pay or repeated product usage.

Moving development forward because you have already invested time

This is sunk-cost thinking.

Validation should still be allowed to kill or reshape the project.

What a strong validation package looks like before development

By the time you are ready to commission or begin a SaaS build, you should ideally have a concise body of evidence rather than a large strategy deck.

It might contain:

a clearly defined target customer, a precise problem statement, notes from customer conversations, documented current workflows, competitor and alternative analysis, the initial value proposition, results from one or more demand tests, pricing feedback, information about the buying process, commercial commitments where possible, and a narrow set of assumptions that still require an MVP.

This material is extremely valuable for a SaaS development team.

Instead of beginning with:

"Build us a CRM for consultants,"

you can begin with:

"Independent consulting firms lose track of client follow-ups because their relationship data lives across email and spreadsheets. We have interviewed 18 firms in one segment, six have reviewed the workflow prototype and three are prepared to pilot a paid version. The first product needs to test whether automated follow-up tracking reduces missed client actions."

That leads to a completely different product conversation.

The technical team can help you design around evidence rather than assumptions.

Validation should make development smaller, clearer and less risky

The purpose of SaaS validation is not to create certainty.

It is to replace expensive assumptions with progressively stronger evidence.

At first, you may only have a belief:

"This problem exists."

Then interviews reveal:

"This specific group experiences it repeatedly."

Research shows:

"They already spend time or money dealing with it."

A landing page or prototype shows:

"They are interested in this particular approach."

A pricing conversation reveals:

"The problem may support this business model."

A pilot agreement or payment demonstrates:

"Someone is prepared to make a real commitment."

Each step reduces uncertainty before the cost of being wrong increases.

That is why the best time to validate a SaaS idea is not after launch.

It is before the architecture, database schema, dashboard and feature backlog become emotionally expensive to change.

The most useful question before writing any code is therefore not:

"Can we build this?"

For most SaaS ideas, the answer is probably yes.

The better question is:

"What evidence do we have that this particular customer has this particular problem badly enough to change behaviour and pay for a better solution?"

Once that answer is strong, development becomes far more focused.

You are no longer building an idea.

You are building the smallest product necessary to serve evidence-backed demand.