You’ve got a SaaS idea that feels like a winner. The features are clear in your mind. You can already picture the dashboard. But here’s the hard truth: most SaaS products fail not because of bad code, but because nobody wanted them in the first place. Building something nobody will pay for is the most expensive mistake you can make as a founder.
Validating your SaaS idea before writing code means proving people will pay for your solution through customer interviews, landing page tests, and pre-sales. This approach saves you months of development time and helps you build something the market actually wants. Focus on conversations and payment commitments, not surveys or assumptions.
Why Most Founders Build the Wrong Thing
Technical founders love building. It’s comfortable. It’s controllable. But that comfort leads straight to a product graveyard.
The pattern repeats itself constantly. A developer spends six months building a feature-rich platform. They launch to crickets. The problem wasn’t execution. The problem was assumption.
You assumed people had the problem you identified. You assumed they’d pay to solve it. You assumed your solution was better than their current workaround. Every assumption you don’t test becomes a landmine in your product roadmap.
Validation flips this script. Instead of building then selling, you sell then build. The order matters more than you think.
Start With Problem Interviews, Not Solutions
Your first job is to confirm the problem exists and hurts enough that people will pay to fix it.
Find 10 to 15 people who might have the problem you’re trying to solve. These should be real potential customers, not your friends humoring you. Reach out through LinkedIn, relevant communities, or cold email. Most people will ignore you. Some will say yes. You only need a handful of conversations to spot patterns.
Structure your interviews around their current experience, not your future product:
- What are you currently doing to handle [problem area]?
- How much time does that take you each week?
- What frustrates you most about your current approach?
- Have you tried other solutions? What happened?
- If this problem disappeared tomorrow, what would that mean for your business?
Notice what’s missing from those questions. You’re not mentioning your idea at all. That’s intentional.
The moment you describe your solution, you bias the conversation. People are polite. They’ll tell you it sounds interesting even if they’d never use it. You want to understand their world before you introduce yours.
Take detailed notes. Record the calls if they agree. You’re listening for pain intensity, not just pain existence. Everyone has minor annoyances. You need problems that cost people time, money, or sanity.
After five interviews, you’ll start hearing repeated phrases. The same complaints surface. The same workarounds appear. Those patterns are gold. They tell you whether you’re onto something real or chasing a problem that doesn’t actually hurt.
Build a Landing Page That Tests Willingness to Pay
Talking to people validates the problem. A landing page validates whether they’ll actually pay for your specific solution.
Your landing page isn’t a placeholder. It’s a sales page for a product that doesn’t exist yet. This feels uncomfortable. That discomfort is the point.
Write clear, specific copy that explains:
- What problem you solve
- How your solution works differently
- What results people can expect
- How much it costs
Yes, put pricing on the page. This is where most founders chicken out. They want to “test interest” without committing to a price. But interest without pricing is meaningless. You need to know if people will pay, not if they’ll click.
Set up a waitlist or pre-order system. Tools like Gumroad, Stripe, or even a Google Form with “I’m ready to pay $X/month when this launches” work fine. The technology doesn’t matter. The commitment does.
Drive traffic to this page through the same channels where you found interview candidates. Post in communities where your target customers hang out. Run small ad tests if you have budget. Send it directly to people you interviewed.
Track everything:
| Metric | What It Tells You | Red Flag Threshold |
|---|---|---|
| Landing page visitors | How well you can reach your audience | Under 100 visitors after two weeks |
| Email signups | Interest level | Under 2% conversion rate |
| Pre-orders or payment commitments | Real buying intent | Under 5% of signups willing to pay |
| Time on page | Message clarity | Under 30 seconds average |
If people won’t give you their email, they won’t give you money. If they’ll give you their email but not a credit card, you’ve got an interest problem, not a demand problem.
The landing page also forces you to articulate your value proposition clearly. If you can’t explain what you’re building in a way that makes strangers want to pay for it, you’re not ready to build anything.
Run a Concierge Test to Prove Your Solution Works
A concierge test means manually delivering your service before you automate it. You do the work yourself, often using spreadsheets, email, and elbow grease.
This sounds backwards. You’re a developer. You want to build software, not run a manual service. But concierge testing teaches you things code never will.
Let’s say you want to build a tool that helps freelancers track invoices and follow up on late payments. Instead of building an app, offer to do this for five freelancers manually. You’ll use a spreadsheet to track their invoices. You’ll send follow-up emails on their behalf. You’ll report results weekly.
Charge them. Even if it’s just $50 per month, money makes it real. Free users will ghost you. Paying customers will give you honest feedback because they’re invested.
This approach reveals problems you’d never anticipate:
- The data you thought would be easy to collect is actually scattered across three different tools
- Customers want weekly reports, but you assumed monthly would work
- The follow-up email templates you drafted feel too aggressive in practice
- Half your customers need a feature you didn’t plan for at all
Every hour you spend doing the work manually saves you weeks of building the wrong features. You’re learning the actual workflow, not your imagined version of it.
Run your concierge test for at least a month. You want to see the full cycle of whatever problem you’re solving. If people renew for a second month, you’ve got something. If they don’t, you’ve learned what’s missing before writing a single line of production code.
The best validation isn’t what people say they’ll do. It’s what they actually do when their own money is on the line. A hundred enthusiastic survey responses mean nothing compared to five people who’ll pay you today for a solution that doesn’t fully exist yet.
Test Demand Through Pre-Sales Before Building
Pre-selling is the strongest validation signal you can get. Someone gives you money for a product that doesn’t exist. That’s not interest. That’s commitment.
This works best for products with clear, immediate value. Project management tools, analytics dashboards, automation software, these all solve current problems that people will pay to fix now.
Create a founder’s tier or early access offer. Price it at a discount from your planned regular pricing, but not so low that it feels like a token amount. If you plan to charge $99 per month eventually, offer early access at $49 per month for the first year.
Be completely transparent. Tell people exactly where you are in the building process. Give them a realistic timeline. Monthly updates are non-negotiable. These early customers are taking a risk on you. Respect that.
Your pre-sale offer needs:
- A clear launch timeline (even if it’s six months out)
- Specific features you’re committing to build first
- A refund policy if you don’t deliver
- A communication plan for updates
Aim to get 10 to 20 pre-sale customers before you start serious development. That number gives you enough revenue to validate demand and enough feedback to guide your roadmap.
If you can’t get 10 people to pre-pay, you have a validation problem. Either your target market is too small, your pricing is wrong, or the problem isn’t painful enough. All of those are good things to learn before you spend three months coding.
Use Analytics to Validate Specific Features
Once you’ve validated the core problem and solution, you still need to validate individual features. Not everything you want to build deserves to be built.
Create a simple features page or roadmap. List the capabilities you’re considering. Ask your pre-sale customers and waitlist subscribers to vote on what matters most to them.
Tools like Canny or even a Typeform survey work here. The key is making people choose. If everything is high priority, nothing is.
Watch for the gap between what people say they want and what they actually use. This comes later, after you have a minimum viable product running. But even in validation, you can test feature ideas through your landing page.
Try creating separate landing pages for different feature sets. Send half your traffic to version A (emphasizing automation features) and half to version B (emphasizing reporting features). See which converts better.
The feature that gets more email signups or pre-orders is the one to build first. Your opinion about what’s cool doesn’t matter. The market’s response does.
Common Validation Mistakes That Waste Your Time
Even founders who try to validate still make predictable mistakes. Avoid these traps.
Talking only to people who already like you. Your mom, your coworkers, your Twitter followers who think you’re smart. These people want you to succeed. Their feedback is contaminated by affection. You need strangers who have zero emotional investment in your success.
Asking hypothetical questions. “Would you use a tool that does X?” is useless. Everyone says yes to hypothetical tools. Ask about current behavior instead. “Show me how you currently handle X” tells you what they actually do, not what they imagine they’d do.
Confusing compliments with commitment. “This sounds great!” is not validation. “I’d probably use this” is not validation. “Here’s my credit card” is validation. Everything else is noise.
Building in stealth mode. You’re worried someone will steal your idea. They won’t. Ideas are worthless without execution. And you can’t validate in secret. You need to put your concept in front of real people and risk rejection.
Waiting for perfect clarity. You’ll never have complete certainty. Validation reduces risk, it doesn’t eliminate it. At some point, you have to make a call with incomplete information. But that call should come after you’ve done the work, not before.
| Validation Method | What It Proves | What It Doesn’t Prove |
|---|---|---|
| Customer interviews | Problem exists and hurts | People will pay for your specific solution |
| Landing page signups | Interest in the concept | Willingness to pay or use regularly |
| Pre-sales | People will pay before it exists | They’ll renew after using it |
| Concierge testing | Your solution actually works | You can automate it profitably |
How Much Validation Is Enough
There’s no magic number. But here’s a reasonable threshold before you start building:
- 10+ customer interviews showing consistent pain points
- 100+ landing page visitors with 5%+ email conversion
- 10+ pre-sale customers who’ve paid real money
- 1+ month of concierge testing with positive feedback
If you hit those numbers, you’ve got enough signal to justify building a minimum viable product. Not a full-featured platform. Not your complete vision. Just the core functionality that solves the main problem you’ve validated.
You’re still taking a risk. Validation isn’t a guarantee. But you’ve dramatically improved your odds. You’re building something people have already told you they want and proven they’ll pay for.
That’s a completely different starting point than “I have an idea I think is cool.”
Moving From Validation to Building
Once you’ve validated demand, your building process changes. You’re not coding in a vacuum anymore. You have customers waiting. You have feedback guiding your decisions. You have revenue expectations to meet.
Start with the smallest possible version that delivers value. If you validated an invoicing tool through concierge testing, your first build should just handle invoice creation and tracking. Payment reminders can wait. Reporting can wait. Integrations can wait.
Ship to your pre-sale customers first. They’re expecting something rough. They signed up knowing you’re early stage. Get the product in their hands fast, then iterate based on how they actually use it.
Set up regular check-ins. Weekly or biweekly calls with your early customers keep you honest and informed. You’ll catch problems immediately instead of three months later when you’ve built everything wrong.
Keep validating as you build. Every new feature idea should go through a mini validation cycle. Is this something customers are asking for? Will they pay more for it? Does it solve a problem they currently struggle with?
Your validation work doesn’t end when you start coding. It becomes part of your ongoing development process.
Why This Approach Saves You Months of Wasted Effort
Every hour you spend validating saves you ten hours of building the wrong thing. The math is that simple.
Developers often see validation as a delay. “I could be building right now instead of talking to people.” But building the wrong product is infinitely slower than building the right one.
A failed product you spent six months on teaches you almost nothing useful. You don’t know if the problem was your execution, your features, your pricing, or your entire premise. You’re left guessing.
Validation gives you data. You know the problem is real because 15 people described the same pain. You know people will pay because 12 of them already did. You know your core features matter because customers ranked them consistently.
When you finally sit down to code, you’re building with confidence. Not certainty, but confidence. You’ve reduced the biggest risks. Now you’re just facing execution risk, which is the risk you’re actually good at managing.
That’s the difference between a validated idea and a guess. Guesses fail quietly and expensively. Validated ideas fail fast and cheap, or they succeed because you built what the market wanted all along.
Your Next Steps Start With Conversations
Stop planning features. Stop sketching wireframes. Stop thinking about tech stacks.
Start by finding five people who might have the problem you want to solve. Send them a message today. Ask if they’ll talk to you for 20 minutes about how they currently handle [whatever your problem area is].
Those five conversations will teach you more than a month of solo planning. They’ll either confirm you’re onto something or redirect you toward a better opportunity. Both outcomes save you time.
Validate your SaaS idea before writing code. Not because it’s the “right” way to build. But because it’s the way that actually works.
