How to validate a SaaS idea before you build?

Learn how to validate a SaaS idea before you build, test real buyer demand, spot weak assumptions, and know what to prove before you invest more.

How to validate a SaaS idea before you build?

When someone says they would use your SaaS product, it will make you feel better about the idea. But when you ask whether they would try it next Tuesday, using their own data, at the price you have in mind then suddenly, you have a much more interesting conversation. This is where SaaS idea validation happens.

A clever person once said on Reddit “getting 10 upvotes on a post doesn’t mean those people will actually use the product once it launches.” They’re 100% right. An upvote tells you someone liked something about your post but it leaves most of the business questions unanswered.

To validate a SaaS idea before you build, identify a specific customer with a recurring problem, investigate how they handle it today, and test whether they will commit to a concrete offer. Then check whether you can deliver that outcome at a workable cost. You don’t need certainty before writing code, just need enough evidence to justify the next investment, and a clear understanding of what remains unproven.

Here’s how to get there.

1. Make the idea specific enough to investigate

“An AI tool that saves agencies time” sounds plausible but it is also difficult to test. Which agencies? Whose time? What work? What happens when that work takes too long?

Start with one customer group and one recurring situation. For example:

“We’re exploring an AI-assisted reporting tool for marketing agencies with 5-20 employees. Account managers would upload campaign exports and receive a draft weekly client report. We think agency owners would pay $99 a month to reduce preparation and review work.” – We’ll use this hypothetical example throughout the article. The customer segment, price and proposed benefits are assumptions to investigate.

Now you have something concrete to work with. You can find agencies of that size, speak to the people preparing reports and ask owners how they choose software. You can also discover that you’re wrong. Perhaps reporting is already easy or preparing the draft takes very little time, while getting clients to agree on what should be measured causes the real frustration. Those findings would lead to different products.

Separate the user from the person who pays

For the reporting tool, an account manager might want less repetitive work. Meanwhile, the agency owner approving the purchase might care about account profitability or whether reports help retain clients. You need to understand both perspectives.

Ask about the last similar tool they bought: “Who suggested it, who approved the budget, and what convinced them it was worth paying for?” This will give you a concrete buying process to investigate rather than assuming the most enthusiastic person can authorize a purchase.

When the user and buyer are different people, ask for an introduction to the person who approves spending. Find out what outcome would justify the price and what they would need to see before approving a pilot. A user saying “I’d use this” is useful feedback but you still need to establish whether the business would fund it.

Write down what would change your mind

Before collecting feedback, decide what evidence would make you build, change direction, or stop. Otherwise, validation gets very easy to manipulate. Positive feedback becomes evidence that the idea is working while negative feedback becomes “they probably weren’t the right ICP.”

For our reporting example, you might write:

“Before building a reporting dashboard, we want agencies in the same segment to show us a recent reporting bottleneck and agree to test a scoped paid pilot.”

Then write down what would make you pause. Maybe agencies already solve the workflow adequately with their current tools or maybe the remaining pain is real but not important enough to spend money fixing. The account manager might hate the process, but the owner does not see enough business impact to change anything. Basically, you ain’t trying to prove the idea is good. You should try to find out which important assumptions still survive contact with reality.

2. Research the problem where people already discuss it

You already know to search on Reddit, LinkedIn and customer communities. Just in case you’re not sure where to look, start with the places your specific SaaS buyer already uses to discuss the problem. If you’re building marketing SaaS, LinkedIn, agency communities, G2 reviews and relevant job posts can be useful. For developer SaaS, GitHub Issues, Stack Overflow and technical communities may reveal far more. For sales or RevOps SaaS, places like LinkedIn, RevGenius, Pavilion, G2 and product support communities can be useful. For vertical SaaS, the strongest signals may sit inside niche industry forums, professional associations or specialist communities rather than general startup channels.

But what is it that you look for once you get there?

Follow the customer, not a generic list of startup communities.

More importantly, don’t just collect complaints. There is a big difference between “Reporting software is annoying.” and “We export everything into Sheets every Friday because our reporting tool can’t handle client-specific metrics.” The second tells you there is already a workaround.

Stronger still would be finding an agency hiring a freelancer to build the reports, paying for several tools, creating an internal solution or actively switching vendors.

As a rough rule, the evidence gets more useful as people move beyond simply complaining about a problem. A recurring problem is more interesting, an existing workaround is stronger, and someone already spending time or money to solve it is stronger still. Purchase or switching behaviour gives you even more to investigate because the problem has become important enough to influence an actual decision.

Also read positive reviews of existing products. You need to know why customers stay, not just why some complain. If you only search for reasons your idea should exist, you will eventually find them.

One final habit: separate what you found from what you think it means. Example:

Observed: Five agencies manually modify client reports after exporting them. Hypothesis: Agencies would pay for software that automates those custom changes.

The first is evidence but the second still needs testing.

This is also where research gets messy quickly. You can find plenty of competitor reviews, customer complaints, market estimates, pricing pages and community discussions. But you still might find it difficult to understand which signals actually matter, which contradict each other, what is still an assumption, and whether the evidence is strong enough to justify building.

This is exactly what NELL Builder helps with.

3. Use NELL to investigate the opportunity before committing to a build

NELL DeepValidate is not just a faster way to research a market. It helps you work out which parts of the idea are actually supported, which are still assumptions, and what could make the opportunity fall apart before you build.

It looks across the problem, demand, competition, pricing, market size and economics using sourced evidence, then surfaces the weak spots instead of simply collecting reasons the idea might work.

Founders can already find plenty of information online. But knowing what that information means for the decision in front of you is the more difficult part. DeepValidate helps structure that decision and shows you what still needs to be tested with real customers before you commit more time and money.

Start with a clear description and the free assessment

Create a NELL account and submit your idea from the dashboard. The onboarding guidance asks for your product description, target industry and professional context, with a market-size estimate optional.

Before a full report runs, the free pre-flight idea gate checks whether the description is vague or off-target and can suggest sharper reframes.

Give it useful context. For our example, the “useful context” would be:

“An AI-assisted reporting tool for small marketing agencies managing at least ten clients. Account managers upload campaign exports and receive a draft weekly report. We want to investigate whether data preparation or written commentary is the bigger problem, what existing tools already solve, and whether owners would consider a $99 monthly offer.”

Quick Validate is the free first pass. It provides a score, dimension breakdown, signal read, biggest unknown and next step. It does not conduct live web research; DeepValidate adds that deeper research layer. Use the first pass to sharpen the idea. Then investigate the direction you’re seriously considering.

Read DeepValidate through its five decision gates

The DeepValidate report organizes the research around five practical questions. Each section of the report feeds into one of those decisions.

Check out the full walkthrough of a real NELL DeepValidate Report.

For the market-sizing sections, focus less on the headline number and more on the assumptions behind it. TAM shows the broad market, SAM narrows that to the portion you can realistically serve, and SOM estimates what you might actually capture. The same applies to the revenue ceiling: it is a model based on assumptions, not a forecast of what you will automatically earn.

Focus on the weakest assumption

In NELL’s INDbench example, the idea is a fractional marketplace connecting pre-seed biotech founders with former FDA reviewers. The report gives it 62/100, “Promising with Caveats.” Its analysis points toward access to suitable experts as an important constraint. This finding changes the next experiment.

Before polishing a marketplace interface, investigate whether the necessary experts would participate on workable terms. The same logic applies to our reporting SaaS. A strong problem assessment would not resolve uncertainty about switching, payment or the amount of human review required. Read the low-scoring sections and the unknowns. Ask what evidence would change them.

Check confidence and sources, not just the score

The score is useful, but the real value is understanding why the idea scored the way it did. DeepValidate shows the evidence behind the major findings and how strong that evidence appears to be. If the research is mixed, incomplete or contradictory, we surface that rather than forcing a confident answer.

The same applies to the overall score. An 80/100 does not mean the idea has an 80% chance of succeeding. It means the idea currently looks stronger across the areas we assess, based on the evidence available.

What matters is what sits underneath that number: where the opportunity looks strong, where the assumptions are still weak, what could derail the idea, and what you should test next with real customers.

Start with NELL’s free Quick Validate to examine your idea, then use DeepValidate when you need the sourced research behind the decision.

But can AI really validate an idea?

A fair objection to AI validation is that AI is not your customer. It cannot buy your product, switch from a competitor or tell you how painful a problem feels inside a real company. And we agree.

DeepValidate is not meant to replace conversations with customers or prove that people will pay. Its job is to do the research around the decision: look for evidence of the problem, existing alternatives, demand, competition, pricing and economics, identify where the assumptions are weak, and tell you what still needs to be tested.

Think of it this way: AI can help you work out what needs proving. Only real customers can prove it. This is why the report ends with experiments and next steps rather than treating the score as the final answer.

4. Talk to prospective customers about their actual work

A founder once asked how to validate a SaaS product with no customers or contacts. There was a whole discussion which exposed a practical problem: even when you find relevant people, getting them to participate seriously is a separate task.

Begin with people you can identify individually. For our reporting tool example, that means agencies matching the proposed team size and workload. Look for account managers and owners through business directories, relevant professional groups, LinkedIn or introductions. Don’t substitute a broad audience of founders for the people who would use and buy the product.

Make the invitation easy to understand

A message could look like this:

“Hi Maya, I’m exploring a product around weekly client reporting for small agencies. Before building anything, I’m trying to understand how teams prepare and review reports today. Would you be open to a 15-minute conversation about your most recent reporting cycle? I’m particularly interested in what still needs manual work.”

The person knows why you contacted them and what you’ll discuss. Where someone agrees, keep that promise. DON’T turn a research invitation into an unexpected sales presentation.

Ask for a recent example

Keep the first part of the conversation focused on what they actually do today, not what they think they might do in the future.

For the agency example, the questions should be:

“Walk me through the last client report you prepared.”

“Where did you get stuck, and what did you do about it?”

“What have you already tried to make that part easier?”

“What happens when the report is late or needs correcting?”

“How did you choose the tools you use now?”

Where possible, ask them to show you the workflow or a recent example with any sensitive information removed. Then investigate urgency. What has made this worth addressing now? A task can be frustrating without being a purchase priority.

Keep observations separate from interpretations

Suppose someone says, “I spend Friday afternoon checking the reports.” The observation is that they spend time checking reports. Your interpretation might be that they need automated quality checks. This remains a hypothesis until you understand what they check and why.

Record the distinction. Also note the people who don’t have the problem. In our example, perhaps agencies with standardized client packages handle reporting easily, while those selling bespoke services struggle. The difference could help you narrow the customer segment.

5. Test an offer people can accept or reject

Once you understand the workflow, put a specific offer in front of prospective buyers. For our hypothetical reporting tool, it could be:

We’re testing a four-week reporting pilot for $99. You provide campaign exports for an agreed set of clients. We prepare draft reports for your review and measure the preparation time together.

Now there is a defined outcome, price and required effort. The conversation can move beyond whether someone likes the idea.

Ask for a commitment that fits the buying process

A paid pilot is useful when the buyer can reasonably approve one. For a more involved purchase, the next meaningful step might be agreement on success criteria, a named pilot owner, an introduction to the budget holder or approval to use representative data. Treat each response for what it establishes.

This is a practical interpretation guide, not a universal ranking. A substantial enterprise pilot commitment may be more informative for that buying process than a token payment from someone outside your target segment.

Keep research incentives separate too. Compensation for an interview is an expense you incurred to learn; it isn’t evidence that the participant would buy.

Use a landing page to test a defined proposition

Your landing page should make the offer concrete: who it is for, what problem it solves, what outcome it promises, and what someone can do next. If pricing is one of the assumptions you need to test, show a real price or pilot offer rather than hiding it behind “join the waitlist.” If the product is still pre-launch, say so clearly.

Then pay attention to the level of commitment. A visitor reading the page is one signal, clicking through to pricing is stronger. Booking a call is stronger again. Paying for a pilot or pre-order tells you something different altogether.

The goal is not simply to collect sign-ups. It is to see how far a relevant buyer is willing to go once the offer becomes specific.

Don’t borrow a conversion threshold without its context

Unbounce’s 2024 benchmark reported a 3.8% median conversion rate for SaaS landing pages, compared with 6.6% across industries. But those conversions include different actions such as demos, trials, downloads and purchases, so it is a useful context, not a pass mark for your idea.

What matters more is who visited the page, where they came from and what you asked them to do. Five sign-ups from 100 highly relevant prospects tells you something very different from five sign-ups generated by broad, low-intent traffic.

And be careful with small samples. If five out of 100 visitors sign up, the observed conversion rate is 5%, but the plausible underlying rate is still quite wide, roughly 2.2% to 11.2% at a 95% confidence level. So don’t build your acquisition model around an early conversion rate until you have more data and know the traffic is representative of the customers you actually want.

Diagnose silence before declaring the idea dead

A Hacker News founder once talked about sharing a waitlist page, hearing encouraging reactions and receiving few sign-ups. They explicitly noted that the people they had spoken with were not their target audience, leaving them unsure whether the idea or distribution was the problem.

Before rejecting an idea after an unsuccessful test, check whether relevant buyers actually encountered a clear offer. Then make one deliberate correction and test again. Don’t keep changing the audience, price and proposition simultaneously; you’ll struggle to understand what the result means.

6. Deliver the outcome and see whether the need returns

You may be able to test the promised outcome before building the full software. For the reporting example, prepare the first reports using existing tools and manual review. Explain how the pilot works. Record the effort involved, the corrections requested and what the customer does with the finished report. You’re investigating whether the outcome is valuable and whether delivering it could become a viable product.

Watch the next natural usage cycle

For a weekly reporting workflow, the next week matters. Does the customer provide another set of inputs? Do they use the output? Do they continue with the arrangement after experiencing the work?

For a monthly workflow, observe the monthly cycle. Don’t use daily activity as a success measure for something the customer only needs at month-end. Also investigate what they value about the pilot. Are they buying the report, your personal interpretation or the relief of having someone handle the entire job?

A successful service pilot is useful evidence indeed. But you still need to test whether the value survives the transition to the software experience you intend to offer.

For AI SaaS, include correction costs

An impressive draft is only part of the result. Using representative customer examples, agree on what “usable” means.

To explain using our reporting example, check whether the figures are correct, explanations are supported and the customer can review the output without rebuilding it. Measure the time spent correcting mistakes alongside the time saved generating the draft. If the customer spends an hour fixing a report that previously took an hour to write, the demo has succeeded more than the product has.

Check whether growth would make economic sense

Use the pilot to replace cost assumptions with observations. In a purely illustrative scenario, a $99 monthly price and $25 in variable monthly delivery costs leave $74 before fixed costs. At an assumed $300 customer acquisition cost, recovering that spend takes about 4.1 months of contribution, provided the customer stays and the costs hold. It is not a forecast it’s just arithmetic.

Include support and human review. Don’t treat your time as permanently free just because you aren’t paying yourself yet. Where retention is unknown, show scenarios. Avoid presenting a precise lifetime value as an observed fact before you have the customer history to support it.

7. Decide what the evidence justifies

At the end of validation, write a decision you can defend. An illustrative decision record:

Several agencies in the same segment showed us the same reporting bottleneck. Three paid for a pilot, and two continued into another reporting cycle. We will build a limited prototype for that workflow. We have not yet established repeatable acquisition or whether delivery can work without extensive manual review.

The decision names both the evidence and its limits.

Proceed with a limited build when you have a defined buyer, a demonstrated problem, meaningful commitment and a plausible delivery model. Keep the product scope tied to what you investigated.

Reshape the idea when the problem appears credible but the proposed customer, price or delivery method doesn’t fit. You may have found a narrower opportunity than the one you started with.

Pause or stop when repeated, relevant tests undermine a critical assumption and you don’t have a credible way to resolve it.

Let the risk determine the experiment

You don’t have to forbid yourself from writing code. When the uncertainty is whether someone cares enough to buy, a sophisticated prototype may leave the important question unanswered. When the uncertainty is whether you can process their data accurately, another opinion survey won’t settle it.

Choose the smallest credible test for the specific uncertainty. That’s also how to avoid endless validation. Set a decision date and a bounded investment for the next experiment. Collect the result, then decide what it earns.

Frequently Asked Questions by SaaS builders

Can you validate a SaaS idea without an MVP?

You can investigate the problem, customer, alternatives and willingness to commit without a complete product. Interviews, workflow reviews, a concrete offer and a manually delivered pilot can answer different questions.

Some assumptions require a prototype, particularly when the value depends on technical performance or integration. Build enough to test that uncertainty.

How many customer interviews do you need?

Use the interviews to resolve questions, rather than reach an arbitrary pass mark. Keep the initial segment consistent and investigate conflicting answers.

You should be able to explain the workflow, urgency, existing alternatives and buying process. A larger pile of loosely relevant opinions does not make those questions disappear.

Does a waitlist validate a SaaS idea?

A waitlist demonstrates interest in the proposition people saw. Follow up to establish who joined, whether they match the intended customer and what they are prepared to do next.

Don’t label an email address as a future subscriber.

Can AI validate a SaaS idea for you?

AI-assisted research can investigate public evidence, organize commercial questions and suggest experiments. NELL DeepValidate supports that research stage, with sources and confidence labels behind its findings.

You still need real prospective customers to react to the offer and, eventually, experience what you deliver.

How long should SaaS validation take?

Tie the work to the uncertainty and the customer’s buying cycle. A price test, a technical prototype and an enterprise pilot approval are different experiments.

Set a deadline for the next decision. Don’t promise yourself that every important question will be settled within the same number of days.

Before you build, know what you’re betting on

You should finish validation with a clearer customer, a more specific offer and evidence that makes the next investment reasonable. You should also know what you haven’t established yet.

A promising market doesn’t settle your acquisition costs and a paid pilot doesn’t establish long-term retention. A useful report doesn’t mean buyers will change how they work.

Start by finding the assumption most likely to change your build decision. Investigate it before spending heavily on everything around it.

Create a free NELL account and start with Quick Validate. When you need the deeper market, competition, pricing and risk analysis, use DeepValidate to prepare the next test.