How to Validate a SaaS Idea Before Building

Before you spend months building your SaaS product, make sure you are solving a problem people actually care enough to pay for.

You have an idea for a SaaS product. Maybe it came from a problem you experienced yourself, something customers have repeatedly complained about, or a gap you noticed while working in a particular industry. The idea seems promising, and it is tempting to start immediately: choose a tech stack, design the interface, hire developers, and build an MVP.

But how do you know whether the idea is actually worth building? How can you find out if there are enough potential customers? Will people pay for the solution, or will they simply say that it sounds useful? And how can you answer these questions without spending months and thousands of euros developing the product?

Steve Blank, one of the people behind the Customer Development methodology, has a simple answer: “There are no facts inside your building, so get outside”. His point is that assumptions made by founders and teams are not evidence. You need to talk to customers, observe how they work, and test your assumptions in the real world.

This is particularly important for SaaS startups because building software has become much easier. Cloud platforms, AI coding tools, no-code products, and open-source technologies mean that a small team can create a working application much faster than it could a decade ago. The problem is no longer necessarily whether you can build the product. The bigger question is whether you should build it in the first place.

Startup failure research repeatedly points to the lack of a real market need as one of the major problems behind failed startups. CB Insights’ analysis of startup post-mortems has identified poor product-market fit and related market problems among the recurring reasons companies shut down.

This is why SaaS validation should happen before serious development begins. In this article, we’ll look at how to test a SaaS idea, how to talk to potential customers, how to research competitors, how to use a landing page or prototype to measure interest, and how to find out whether customers are actually willing to pay.

Start With the Problem, Not the Product

One of the easiest mistakes to make as a founder is to become attached to the product before understanding the problem.

It often starts with a sentence like, “I want to build an AI-powered platform for…” From there, the rest of the thinking becomes focused on features. What should the dashboard look like? Should there be an AI assistant? Which integrations should be included? Should the product have a mobile app?

These are important questions eventually, but they are not the first questions you need to answer. The first question is much simpler: what problem are you solving, and for whom?

Imagine that you want to build software that automatically creates marketing reports for agencies. Instead of immediately asking potential customers whether they would use your product, ask them how they create reports today.

You might discover that an agency spends five hours every Monday exporting data from Google Ads, Meta, and several other platforms, putting everything into a spreadsheet, checking the numbers, formatting charts, and sending the final report to clients.

Now you have something worth investigating. The problem isn’t “agencies need AI reporting software.” The problem is that a particular group of people spends several hours every week doing repetitive reporting work. That is a much more concrete starting point.

This distinction matters because customers don’t necessarily want your product. They want the result that your product can provide. A company doesn’t buy project management software because it wants another dashboard. It buys it because it wants projects to be easier to manage. A sales team doesn’t necessarily want another CRM. It wants a better way to manage leads and close deals.

The closer you get to the underlying problem, the easier it becomes to understand whether there is a business opportunity.

Find Out How People Solve the Problem Today

Once you have identified a problem, don’t immediately start designing your solution. Find out what people are doing without you. This is one of the most useful parts of SaaS validation because existing behavior gives you much better information than hypothetical answers.

If you ask someone, “Would you use a tool that automatically creates your reports?” they might say yes. It sounds useful, and there is very little reason for them to say no. But if you ask, “Can you walk me through the last time you created a report?” the conversation becomes much more interesting.

Maybe they use Excel. Maybe they have a complicated collection of spreadsheets. Maybe an employee spends half a day doing it manually. Maybe they already pay €300 a month for another platform but still have to export the data and clean it themselves. These details are much more valuable than a simple “yes”.

Look for evidence that the problem already exists in someone’s workflow. If people have created spreadsheets, scripts, processes, or workarounds to deal with the problem, that is a strong indication that it is not purely theoretical.

It is also worth asking what happens if they don’t solve the problem. Does somebody have to spend another five hours doing manual work? Does the company lose customers? Does an employee have to work overtime? Does management make decisions using outdated information?

The consequences help you understand how important the problem really is. A problem that is slightly annoying once a year is unlikely to become a successful SaaS business. A problem that costs a team several hours every week is a different story.

Talk to Potential Customers Before Writing Code

Customer interviews are probably the most underestimated part of startup validation. Founders sometimes avoid them because talking to customers feels less productive than building something. Opening Figma and creating a dashboard gives you something tangible at the end of the day. Spending an hour talking to someone about their workflow can feel less concrete.

But those conversations can save months of development. The key is to avoid turning the interview into a sales pitch. Instead of explaining your product and asking whether the person likes it, ask about their experience.

For example, if you’re thinking about building software for recruitment teams, you could ask how they currently track candidates, where information gets lost, how much time recruiters spend updating systems, what tools they use, and which parts of the process are particularly frustrating.

Ask about something that actually happened rather than what someone thinks might happen in the future. “Tell me about the last time you had to do this” is usually more useful than “Would you use a tool that did this automatically?”

You should also pay attention to how people describe the problem. If someone immediately starts telling you about a workaround they’ve built, that’s interesting. If they say, “It’s annoying, but we only deal with it once every few months,” that’s also useful information. You are not trying to collect compliments about your idea. You are trying to understand whether the problem is real, frequent, expensive, and important.

Don’t Be Afraid of Competitors

Finding competitors is not necessarily bad news. If there are already several products solving the problem, it means someone has already identified a market. The existence of competition can actually make validation easier because you have real customers and real products to study.

The important question is not simply: Who are my competitors? It is: Why would someone choose my product instead?

Look at existing products, but also look at their reviews. G2, Capterra, Reddit, industry communities, and product forums can be particularly useful here. Customers often explain exactly what they dislike about software they already use.

You might discover that an established product has all the functionality you need, but it takes weeks to implement. Perhaps it is designed for enterprise companies and is too complicated for small businesses. Maybe the pricing is difficult to understand, or a critical integration is missing.

That can give you a starting point. You don’t necessarily need to create a product that is completely different from everything else on the market. You need a reason for a particular customer to choose your product.

For a startup, that might mean focusing on a narrow customer segment instead of trying to serve everyone.

For example, “CRM for businesses” is a huge and vague market. “CRM for small architecture firms that manage long sales cycles” is much more specific. A narrow starting market can make customer research, positioning, and product development considerably easier.

Use a Landing Page to Test Interest

Once you’ve talked to potential customers and have a better understanding of the problem, you can start testing your proposed solution.

You don’t necessarily need a working application. A simple landing page can be enough to see whether your message attracts interest.

The page should explain what the product does, who it is for, and what problem it solves. You can then invite visitors to join a waitlist, request early access, book a demo, or sign up for a beta. The important part is where the traffic comes from.

If you send 1,000 random visitors to your website, the resulting conversion rate may tell you very little. If you can put the page in front of 100 people who actually belong to your target market, their behavior becomes much more meaningful.

For example, suppose you are building software for small accounting firms. You could share the landing page in relevant professional communities, contact accounting firms directly, run a small advertising experiment, or speak to people you’ve already interviewed.

If nobody is interested after seeing a clear explanation of the problem and solution, that is worth investigating before you build. If people start signing up, replying to your emails, asking when the product will be available, or requesting a demo, you have stronger evidence that the idea deserves further testing. A landing page is not proof of product-market fit. It is simply another experiment.

Build a Prototype, Not a Full Product

The next step doesn’t have to be an MVP with authentication, databases, billing, integrations, analytics, and a polished dashboard. In many cases, a prototype is enough.

The purpose of the prototype is to help potential users understand what you are proposing and allow you to observe how they react to it. For example, imagine you’re developing a SaaS product that helps companies manage employee onboarding. Instead of building the complete platform, you could create the main onboarding flow in Figma or another prototyping tool.

Then give it to several HR managers and ask them to perform a task. Don’t explain every screen. Watch what they do. Do they understand where to start? Do they expect a different workflow? Do they immediately understand the value? Do they ask about integrations that you hadn’t considered?

These sessions can reveal problems that aren’t obvious from interviews.

Google’s Design Sprint methodology is built around a similar principle: teams can prototype and test ideas with users before committing to building the final product.

For an early SaaS startup, the prototype is not about creating something beautiful. It is about testing whether the proposed experience makes sense.

The Most Important Test: Will They Pay?

Interest is useful. Payment is better evidence. This is where a lot of SaaS ideas become less convincing. People may tell you that your product is useful. They may sign up for a waitlist. They may even ask when it launches.

But when you tell them the price, everything changes. That’s why pricing shouldn’t be treated as something you figure out after development. You can start testing it surprisingly early.

You don’t necessarily need to charge everyone immediately. You can offer an early-access plan, a paid pilot, or a limited beta.

Imagine you’ve interviewed 20 companies and eight say they would be interested in trying your product. You could tell those eight companies that the initial version will cost €49 per month.

Now you have a much more useful conversation. Some will say yes. Some will say no. Some will tell you that €49 is too expensive. Others might say they would happily pay €100 if you add a particular integration. All of those answers are useful.

The important thing is to understand that willingness to pay is different from perceived usefulness. A product can be useful and still not represent a strong commercial opportunity if customers aren’t willing to pay enough to support the business.

Try a Concierge MVP

There is another approach that works particularly well for SaaS: don’t automate everything at first. Instead, deliver the result manually. This is sometimes called a concierge MVP.

Imagine you want to build a SaaS product that automatically creates weekly sales forecasts. Building the complete product might take months. Instead, find five companies that have the problem. Ask them to provide their data and manually prepare the forecast for them.

It isn’t scalable, but scalability isn’t the question yet. You want to know whether customers actually value the result.

If they use the forecast, ask for another one the following week. See whether they start depending on it. Ask what they would change. Ask how much the result is worth to them. If customers keep asking for it, you have learned something important.

You can then start automating the process step by step. This approach can also prevent a common startup mistake: spending months automating a workflow that customers don’t actually care about.

Measure Evidence, Not Just Activity

One of the problems with validation is that almost any result can be interpreted positively if you want it badly enough. Ten people signed up? Great. Only ten out of 1,000 visitors signed up? Maybe that’s still great. Someone said they’d pay? Great. But did they actually pay? This is why it helps to decide beforehand what evidence would change your decision.

For example, you might decide that you want to speak to 20 potential customers before building anything. If only two describe the problem as important, that’s a signal that you should reconsider your assumptions.

Or perhaps you test a prototype with ten people and most of them struggle to understand the main workflow. That’s useful information too.

The exact numbers will vary depending on the product and market. A €10/month consumer SaaS and a €20,000/year enterprise product obviously require different validation processes.

What matters is that you are measuring something meaningful. A large number of website visitors is not necessarily meaningful. A smaller number of highly relevant people asking when they can buy the product can be.

Give Yourself Permission to Change the Idea

One of the hardest parts of validation is accepting evidence that doesn’t support your original idea. You might start by thinking that freelancers are your ideal customers. After talking to them, you discover that most don’t consider the problem serious enough to pay for a solution.

But then you speak to small agencies and discover that the same problem costs them several hours every week.

Your original idea wasn’t necessarily wrong. Your initial customer segment may have been. This is where validation becomes useful. The goal isn’t to prove that your first idea is correct. The goal is to learn enough to find a business worth building.

That might mean changing the customer segment, changing the pricing model, changing the product, or even solving a different problem discovered during the research.

A startup that changes direction before spending six months building the wrong product has not wasted six months. It has potentially avoided wasting them.

A Simple Validation Process for a SaaS Startup

You don’t need a complicated framework to get started. Spend the first few days defining the problem and the customer. Write down what you believe to be true. Who has the problem? How often does it happen? How are they solving it today? Why would they pay for something better?

Then talk to potential customers. Try to get beyond your personal network. Friends and colleagues can provide useful feedback, but you want conversations with people who actually fit the market you are considering.

At the same time, research the existing market. Look at competitors, customer reviews, forums, communities, and discussions around the problem. Once you understand the problem better, create a simple landing page or prototype and put it in front of potential customers.

Finally, test pricing. At the end of this process, you should have more than an opinion about your idea. You should have evidence. Maybe the evidence tells you to build. Maybe it tells you to change the idea. Maybe it tells you to stop. All three outcomes are valuable.

What Should You Know Before You Start Building?

Before moving into serious development, you should have a reasonably clear answer to one question: Why will someone choose this product instead of doing nothing or continuing to use what they already have?

You should understand who that person is, what problem they have, how they solve it today, and what makes the problem important enough to spend money on.

You should also have spoken to real potential customers rather than relying entirely on market reports or your own assumptions.

And ideally, you’ve tested some version of the solution. It doesn’t need to be perfect. It doesn’t even need to be automated. You just need enough evidence to justify the next investment. That is the real purpose of validation.

From a Validated Idea to a Working SaaS with Flatlogic

Once you’ve validated your SaaS idea and have evidence that customers are interested, the next challenge is turning that idea into a working product. For an early-stage startup, traditional development can take months and require a significant investment before you even have something customers can use.

Flatlogic helps startups move from a validated concept to a functional web application faster with AI-assisted development. Instead of starting from an empty codebase, you can describe the application you want to create and generate a working foundation that can be customized and developed further.

The important part is that Flatlogic fits after validation, not instead of it. Once you’ve talked to potential customers and identified the features that actually matter, you can focus development on those core workflows rather than spending time building features based on assumptions.

For example, if your research shows that small agencies mainly need project tracking, task management, and client visibility, you can start with those capabilities rather than trying to create a complete project-management platform from day one. As real users start using the product, their feedback can guide what you build next.

This creates a practical cycle for SaaS startups: identify a problem, validate demand, build the core product, collect feedback, and iterate. With the right validation work done upfront, AI-assisted development can help you move through the building stage faster and spend more time improving a product that already has evidence behind it.

Conclusion

The easiest time to change a SaaS product is before you’ve built it. Once developers have spent months writing code, designs have been finalized, integrations have been built, and money has been invested, changing direction becomes much harder. That’s why the early stage of a SaaS startup should be less about building and more about learning.

Talk to customers. Understand how they solve the problem today. Study competitors. Test your positioning. Create a simple prototype. Put a price on the solution and see what happens.

None of these experiments can guarantee that a startup will succeed. But they can help you replace assumptions with evidence. And that can make a huge difference.

Modern development tools make it possible to turn an idea into a working SaaS application faster than ever. Platforms such as Flatlogic can help startups move from a validated concept toward a functional application without spending months building every part of the foundation from scratch.

But the technology should come after the validation. Don’t start by asking how quickly you can build the product. Start by finding out whether there is a product worth building.