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

Most SaaS ideas do not die because the code was bad. They die because nobody wanted the product in the first place.

If you have ever spent three months building something, launched it with real excitement, and then watched the signup counter sit at zero, you know exactly how this feels. The painful part is not the lost time. It is realizing that a handful of honest conversations and a simple landing page could have told you the truth before you wrote your first line of code.

At StartupsMap, we look at a lot of new startups. The ones that find traction early usually share one habit: their founders proved people wanted the product before they built most of it. This guide shows you how to do the same thing, step by step, using methods that actually worked for Buffer, Dropbox, Zapier and Nomad List.

Quick summary: the 8 steps

Write the problem down in one sentence
Go where people already complain
Talk to 15 to 20 potential customers
Study the competition
Build a landing page with a pricing page
Show the product without building it
Ask for money
Deliver the result manually first

Why validation matters more than your code

When CB Insights studied over a hundred startup post mortems, the most common reason for failure was not running out of money or a weak team. It was "no market need," cited by 42 percent of the founders. Running out of cash came second at 29 percent.

Think about what that means. Nearly half of those companies built something that worked, at least technically, but solved a problem people did not care enough about. They had the skills. They just pointed them at the wrong target.

This matters even more today. With AI coding tools, you can build a working MVP in a weekend. Building has become cheap. Knowing what to build has not. When anyone can ship a product in days, the founder who understands the customer best is the one who wins.

Validation is how you get that understanding without betting months of your life on a guess.

What validation actually means

Here is the trap most first time founders fall into. They describe their idea to friends, family and a few people on Twitter, everyone says "that sounds great," and they take that as validation.

It is not. Compliments cost nothing. People are polite, and most of them will tell you what you want to hear because they like you, not because they would ever pay for your product.

Real validation is when someone gives up something they value to get what you are offering. That could be:

Their time, like booking a call or joining a waitlist and actually showing up
Their reputation, like introducing you to their manager or sharing your page with their team
Their money, like paying a deposit, preordering or buying a beta plan

The more someone gives up, the stronger the signal. An email signup is a weak yes. A credit card is a strong one. Keep this in mind through every step below, because the goal is always to move people from saying nice things to making real commitments.

The 8 step process to validate your SaaS idea

You do not need to do every step perfectly, and you do not need to follow them in strict order. But if you work through all eight, you will know far more about your idea than most founders do on launch day.

Step 1: Write the problem down in one sentence

Before you think about features, write down the problem you are solving and who has it. Use this simple format:

[A specific type of person] struggles with [a specific problem] when [a specific situation], and today they handle it by [their current workaround].

For example: "Freelance designers struggle to get paid on time when clients delay invoices, and today they handle it by sending awkward reminder emails manually."

If you cannot fill in every part of that sentence, you are not ready to validate yet. "Small businesses" is not a customer. "Productivity" is not a problem. The more specific you are, the easier every next step becomes.

Pay close attention to the last part, the current workaround. If people are not doing anything about the problem today, not even a messy spreadsheet, that is a warning sign. It usually means the pain is not strong enough for them to pay for a fix.

Step 2: Go where people already complain

Your future customers are already talking about their problems online. You just have to find them.

This is exactly how Zapier found its first users. Wade Foster, the cofounder, went through the support forums of popular apps and looked for people asking for integrations that did not exist yet.

Then he reached out to those people directly.

Nobody in those threads was asking for a product like Zapier. They were simply asking for one app to talk to another. Wade connected the dots and saw the bigger opportunity.

Here are the best places to dig:

Reddit: Search your niche subreddits for phrases like "is there a tool for," "how do you handle," or "I hate when."
Review sites like G2 and Capterra: Read the 2 and 3 star reviews of existing tools. These are gold, because they show what paying customers wish was better.
Product forums and community boards: Feature request threads tell you what users want and are not getting.
Upwork and Fiverr: If people are paying freelancers to do a task over and over, there might be room for software that does it for them.
Indie Hackers, Hacker News and LinkedIn: Great for B2B and developer focused ideas.

Save every complaint you find in a simple spreadsheet. After a few days, patterns will jump out at you, and you will often find the exact words your customers use. Those words become your landing page copy later.

Step 3: Talk to 15 to 20 potential customers

This is the step most founders skip, and it is the one that matters most. You need real conversations with the people you identified in Step 1.

The secret is to ask about their past behavior, not your idea. If you ask "Would you use a tool that does X?" almost everyone will say yes, and it means nothing. Instead, ask questions like these:

Tell me about the last time you dealt with this problem. What happened?
How are you solving it right now?
How much time or money does this cost you each month?
Have you tried any other tools for this? Why did you stop using them?
If you could wave a magic wand, what would change?

Then stay quiet and listen. Let them talk. The best insights usually come after an awkward pause.

If you want to get better at this, read The Mom Test by Rob Fitzpatrick. It is a short book, and it will completely change how you run customer conversations.

You can find people to talk to through LinkedIn messages, the communities from Step 2, your own network, or by commenting helpfully on posts where people share the problem. Offer to keep the call to 15 minutes. Most people are happy to talk about their frustrations when you are genuinely curious.

Step 4: Study the competition, and do not panic

Many founders search for competitors, find a few, and give up. That is usually a mistake.

Competition is often a good sign. It means people already pay to solve this problem. What you are looking for is a gap: a type of customer the big players ignore, a feature everyone complains about, or a price point that leaves a segment underserved.

For each competitor, note down their pricing, who they target, and the most common complaints in their reviews. If every review of a popular tool says it is too complicated for small teams, you may have just found your positioning.

The real red flag is the opposite: a problem that seems obvious but has zero competitors and nobody discussing it anywhere. Sometimes that is a hidden opportunity. More often, it means nobody cares enough to pay.

Step 5: Build a landing page with a pricing page

Now it is time to test whether strangers, not just the people you spoke with, care about your solution.

Buffer is the classic example here. Before writing any code, founder Joel Gascoigne put up a simple landing page that explained the idea of scheduling tweets. When visitors clicked to sign up, they were told the product was not ready yet and were asked for their email.

Once people were signing up, Joel added one clever extra step. Between the landing page and the email form, he inserted a pricing page with three plans: free, $5 and $20.

Now visitors had to pick a plan before leaving their email. That told him two things at once: whether people were interested, and whether they were willing to pay.

Joel later said the real value was in the conversations that came from those signups, not the signup count itself.

You can do the same thing today in a few hours using tools like Carrd, Framer or Webflow. Your page should include:

A headline that names the problem in your customer's own words
Three or four lines on how your product solves it
A clear pricing section, even if the prices are your best guess
A call to action like "Get early access" that leads to an email form

Then send traffic to it. Share it in the communities you found in Step 2, message the people you interviewed, and post about it on X and LinkedIn. You do not need thousands of visitors. A few hundred targeted ones will tell you a lot.

Step 6: Show the product without building it

Some products are hard to explain with words alone. In that case, show people what it will look like.

Dropbox had this exact problem. File syncing was a new idea, and the product was technically hard to build.

Drew Houston first tried buying Google ads. The results were terrible.

So he recorded a simple three minute screen recording showing how Dropbox would work, with a few inside jokes for the tech crowd. After the video took off, the beta waiting list jumped from about 5,000 people to 75,000, literally overnight.

That told him the demand was real before the product was even finished.

Pieter Levels took an even simpler route with Nomad List. Instead of building a website, he made a public Google spreadsheet ranking cities for remote workers by cost of living, internet speed and more. Then he shared it on Twitter.

People started adding data and new columns themselves. That level of engagement was enough proof for him to turn it into a real website.

Your version could be:

A short Loom video walking through a mockup
A clickable Figma prototype
A Notion page, Airtable base or Google Sheet that delivers the core value
A simple no code version built with tools like Bubble, Softr or Glide

The goal is not to impress anyone. It is to see whether people lean in and ask "when can I use this?"

Step 7: Ask for money

This is the step that makes most founders uncomfortable, and it is the one that gives you the clearest answer.

Pieter Levels summed it up in the title of one of his blog posts: "The only real validation is people paying for your product." Signups, likes and kind words are all useful, but they are not proof.

Zapier took this seriously. During the beta, when the product was still rough, they charged early users a one time fee that started as high as $100 and later dropped to $10.

Wade Foster has explained that this small hurdle brought in high quality users who gave much better feedback.

Buffer, meanwhile, got its first paying customer within three days of launching. That single $5 payment did more for Joel's confidence than any number of email signups.

Ways you can ask for money before the product is ready:

Preorders: Sell lifetime deals or discounted annual plans to your waitlist.
Paid beta: Charge a small fee for early access and direct input on the roadmap.
Letters of intent: For B2B products, ask companies to sign a simple note saying they will buy if you deliver specific features.
Deposits: Take a refundable deposit to reserve a spot.

If ten people out of a hundred interested ones pay you something, you have a real signal. If nobody pays, even at a low price, that is not failure. That is valuable information you got before spending six months building.

Step 8: Deliver the result manually first

Before you automate anything, try delivering the outcome by hand. This is often called a concierge MVP.

Say your idea is a tool that writes weekly reports from a company's sales data. Instead of building the whole system, ask three customers to send you their data, create the reports yourself using spreadsheets and AI tools, and email them back every Monday. Charge for it.

You will learn which parts of the report people actually read, what format they prefer, and what they would happily pay more for. When you finally build the software, you will be automating something you already know people want, instead of guessing.

It does not scale, and it is not supposed to. It is supposed to teach you.

How to read the signals

After a few weeks of this work, you need to decide: build, change direction, or drop the idea. Look at these six signals as a quick gut check.

1. Customer conversations

Good sign: People describe the problem in detail and get a little emotional about it.
Warning sign: People agree politely but cannot remember the last time it happened.

2. Current workaround

Good sign: They use messy spreadsheets, pay freelancers or stitch several tools together.
Warning sign: They do nothing about it and seem perfectly fine.

3. Follow up

Good sign: They ask when they can try it and offer to introduce you to others.
Warning sign: They go quiet after the call.

4. Landing page

Good sign: A meaningful share of targeted visitors click through pricing and leave an email.
Warning sign: Visitors bounce, or only your friends sign up.

5. Money

Good sign: Some people preorder, pay for a beta or sign a letter of intent.
Warning sign: Everyone loves it, but nobody will pay even a small amount.

6. Competition

Good sign: Competitors exist, and their reviews show clear, repeated complaints.
Warning sign: No competitors and nobody discussing the problem anywhere.

You will rarely see only good signs. Pay the most attention to Money and Follow up. If those two look good, you have a strong reason to start building. If they look bad, no amount of positive feedback elsewhere should convince you.

Common mistakes to avoid

Only talking to friends and family. They love you, so they will be kind. Talk to strangers who actually have the problem.

Pitching instead of listening. If you spend the call explaining your idea, you learn nothing. Your job in early conversations is to understand their world, not sell yours.

Treating signups as proof. An email address is free to give. Push for a stronger commitment before you call the idea validated.

Targeting everyone. "Any business that sends invoices" is too broad to validate. Start with one narrow group, prove it there, then expand.

Falling in love with the solution. Your idea is a guess about how to solve a problem. Stay loyal to the problem and be willing to change the solution as you learn.

Validating forever. Research can become a comfortable way to avoid risk. Set a deadline, maybe three or four weeks, then make a decision based on what you have.

Ignoring a clear no. If nobody will pay and conversations keep going nowhere, accept it. Killing a weak idea quickly frees you to find a strong one.

What to do once your idea is validated

Validation does not end when you start building. It just changes shape. Here is what to do next.

Build the smallest version that solves the core problem. Buffer launched with one feature: scheduling tweets. That was enough. Resist the urge to add everything your interviewees mentioned.

Keep your early users close. The people who paid for your beta or joined your waitlist are your most valuable asset. Message them personally, onboard them yourself, and ask for feedback every week.

Get your startup in front of more people. Once you have something live, put it where founders, early adopters and potential customers are already looking. You can list your startup on StartupsMap for free so more people can discover what you are building. It takes a few minutes and gives you another source of early users and feedback.

Measure product market fit with the 40 percent test. Once you have real users, ask them one question: "How would you feel if you could no longer use this product?" Give three options: very disappointed, somewhat disappointed, or not disappointed. Growth expert Sean Ellis found that companies where at least 40 percent of users answer "very disappointed" tend to grow much more easily.

Superhuman used this exact survey. Their first result was just 22 percent. Instead of guessing, founder Rahul Vohra focused on the users who loved the product, figured out why, and fixed what held back the "somewhat disappointed" group. Within about a year, the score climbed to 58 percent. Validation, in other words, is something you keep doing for the life of your product.

At Last!

Validating an idea is not glamorous. It means sending cold messages, sitting through awkward calls, and hearing people say they would not pay for something you were excited about. But a few weeks of that discomfort can save you months, or even years, of building the wrong thing.

The founders behind Buffer, Dropbox, Zapier and Nomad List were not luckier than you. They simply refused to bet everything on a guess. They used a landing page, a short video, a spreadsheet and a forum post to find out what people really wanted, and then they built exactly that.

You can start today. Write your one sentence problem statement, find ten people who have that problem, and talk to them this week. By the time you open your code editor, you will know you are building something people actually want.

And when you are ready to launch, list your startup on StartupsMap and let the right people find you.