How to Validate a SaaS Idea Before Writing Code

I once spent four months building a SaaS product that nobody wanted. Not “nobody signed up” — I mean literally zero people cared enough to even try it for free. Four months of evenings and weekends, gone.

The painful part wasn’t the wasted code. It was realizing I could have figured this out in a week if I’d just talked to people first.

The number one reason startups fail is no market need. Not bad code, not ugly design, not slow servers. People simply didn’t need what was built. And developers are especially prone to this because building is the fun part. Validation feels like homework.

Here’s the process I use now to validate a SaaS idea before I write a single line of code.

The Only Validation That Actually Matters

Let’s get this out of the way: interest is not validation. Payment is.

Someone saying “oh cool, I’d totally use that” means nothing. People are polite. They’ll tell you your idea is great because saying “I don’t care about this” feels rude.

Real validation signals look like this:

• Someone asks when they can sign up
• Someone offers to pay before the thing exists
• Someone talks about your idea to other people without you asking them to
• Someone describes the exact problem you’re solving, unprompted

If you’re collecting “that’s interesting” responses, you’re collecting noise. You need people reaching for their wallets.

Step 1: Become the Product Yourself (Days 1-5)

Before you build anything, do the thing manually.

If your idea is a tool that converts blog posts into Twitter threads, do it by hand for 10 people. If it’s an invoice generator for freelancers, generate invoices for freelancers using a spreadsheet.

This does two things:

1. You learn the actual problem. Not the problem you imagined, but the one people really have. The edge cases, the frustrations, the workflow they’re already using.
2. You find out if anyone will pay. If you can’t get someone to pay you $20 to do this manually, they won’t pay $20/month for software that does it.

This is what I call the “become the product” phase. You are the MVP. Your brain is the server, your hands are the API.

Research your competitors during this phase too. Look at what exists, what people complain about in existing tools, and where the gaps are. Check Reddit, Twitter, Indie Hackers forums, and G2 reviews. If there are zero competitors, that’s usually a bad sign — it might mean there’s no market.

Step 2: Have 20 Real Conversations (Days 6-10)

Not surveys. Not Twitter polls. Actual conversations with people who might pay for this.

Find 5-10 potential users and talk to them. Not about your idea — about their problems. The goal is to understand their workflow, their pain points, and what they’ve already tried.

Good questions:

• “What’s the most annoying part of [process your tool would improve]?”
• “How are you handling this right now?”
• “Have you tried any tools for this? What didn’t work?”
• “How much time do you spend on this per week?”

Bad questions:

• “Would you use a tool that does X?” (They’ll say yes to be nice.)
• “How much would you pay for this?” (They’ll lowball or make something up.)
• “Don’t you think X is a problem?” (You’re leading the witness.)

After 20 conversations, patterns emerge. You’ll hear the same complaints, the same workarounds, the same frustrations. That’s your signal.

If after 20 conversations nobody seems particularly bothered by the problem you’re solving, that’s a signal too. A clear one.

Step 3: The Fake Door Test (Days 11-15)

Build a landing page. Describe the product. Add a pricing section. Put a “Sign Up” or “Buy Now” button on it.

When someone clicks that button, they get a page that says: “We’re launching soon. Enter your email to get early access and a 30% discount.”

This is the fake door test. You’re measuring how many people are willing to take action, not just read your copy and bounce.

Drive traffic to this page:

• Post in relevant Reddit communities (genuinely, not spammy)
• Share in Slack and Discord groups where your audience hangs out
• Run a small ad spend ($50-100 on Google or Twitter)
• Post on Indie Hackers, Hacker News, or Product Hunt upcoming

Track two metrics: click-through rate on the buy button and email signups. If you’re getting a 5%+ click rate on the pricing CTA and collecting signups, you’re onto something.

Step 4: The Money-Back Guarantee Test

This is the step most people skip, and it’s the most important one.

Sell the product before it exists.

Put up a real payment page. Charge real money. Offer a 100% money-back guarantee. When someone pays, deliver the service manually — you already practiced this in Step 1.

“But that doesn’t scale!” Correct. It’s not supposed to. You’re not scaling, you’re validating. You’re answering one question: will a stranger on the internet give you money for this?

If 3-5 people pay you actual money for a manual version of your product, you have validation. Real validation. The kind backed by credit card transactions, not Reddit upvotes.

This is also where you figure out pricing. If you’re not sure where to start, I wrote about how to price your SaaS side project — it covers the psychology and math behind finding your number.

Step 5: Now You Can Write Code

You’ve talked to real people. You’ve done the work manually. You’ve collected actual payments. Now you know three things:

1. The problem is real
2. People will pay to solve it
3. What the solution actually needs to do (and what it doesn’t)

This is when you open your editor. Not before.

And when you do start building, build the smallest possible version. If you’ve been looking at micro SaaS ideas you can launch quickly, you already know that a weekend MVP beats a six-month masterpiece every time.

Your first version needs auth, payments, and the core feature. That’s it. For the auth and payments part, Beag.io handles both in about 5 minutes so you can focus on the thing that actually makes your product unique.

The 30-Day Validation Timeline

Here’s the compressed version:

Days	Activity	Goal
1-5	Research competitors, do the job manually	Understand the real problem
6-10	Have 20 conversations with potential users	Find patterns in pain points
11-15	Fake door test with landing page	Measure real interest with actions
16-20	Sell manually with money-back guarantee	Get actual payments
21-25	Analyze results, decide go/no-go	Make an evidence-based decision
26-30	Start building MVP (if validated)	Ship the smallest useful version

You can compress this further. Some people validate in a weekend. But the sequence matters more than the speed: research, conversations, fake door, real payments, then build.

Red Flags That Kill Ideas

Stop and reconsider if you see these:

• Nobody responds to your outreach. If you can’t get 20 people to talk to you about their problem, the problem might not be painful enough.
• Everyone says “cool idea” but nobody asks to sign up. Politeness is not demand.
• You can’t find anyone doing this manually. If nobody is solving this problem with duct tape and spreadsheets, they might not need a solution.
• The only people excited are other builders. Developers think everything is cool. Your customers need to think it’s worth paying for.
• You keep pivoting the pitch. If you’re changing your description every conversation to get a positive reaction, you don’t have product-market fit — you have a solution looking for a problem.

FAQ

How many paying customers do I need to consider an idea validated?

Three to five actual payments from strangers (not friends, not family) is a strong signal. The number matters less than the fact that someone you don’t know pulled out their credit card.

What if my idea is B2B and I can’t do a fake door test easily?

Adjust the approach. Send cold emails offering to solve the problem as a consulting engagement. If a company will pay you $500 to do it manually, they’ll likely pay $50/month for software that does it automatically.

Should I validate if I’m building something for myself?

Yes, but with a caveat. If you’re your own target customer and you’d genuinely pay for it, that’s one data point. You still need 4-9 more people who feel the same way. “I’d use this” from the person building it is the weakest possible signal.

How do I handle people who want features my MVP won’t have?

Write them down. Don’t build them. Your validation is about the core problem, not feature completeness. If people pay for the basic version, you can add features later based on what paying customers actually request.

What if someone already built this exact thing?

Competition is usually a good sign — it means the market exists. Look at their reviews, find what people complain about, and build something that solves those specific complaints better. A crowded market with unhappy customers is better than an empty market.

---

Ready to turn your validated idea into a real product? Skip the weeks of auth and payment integration.

Add auth + payments to your app in 5 minutes with Beag.io