The Most Expensive Mistake in SaaS? Building Something Nobody Wants.
The graveyard of failed SaaS products is full of technically impressive software that solved problems nobody had. According to CB Insights' analysis of startup failures, 35% of startups fail because there's no market need — making it the single most common reason for failure.
The fix is boring but effective: validate before you build.
Validation doesn't require months of research or thousands of dollars. It requires structured thinking and honest answers to hard questions. Here are seven steps that separate ideas worth building from ideas that waste your time.
We learned this the hard way while building VibeGen. Before settling on AI-powered project planning for indie hackers, we explored — and discarded — three other concepts that didn't survive validation. The process described here is what we actually used, refined from firsthand experience.

📝 Step 1: Define the Problem in One Sentence
Every viable SaaS starts with a real problem experienced by real people. Not a hypothetical inconvenience — a concrete pain point that costs someone time, money, or sanity on a recurring basis.
Use this format:
"[Target audience] struggles with [specific problem], which causes [measurable consequence]."
Example: "Indie hackers spend 20+ hours researching whether a project idea is viable, which delays their launch by weeks."
If the consequence isn't painful enough for someone to pay money to solve it, reconsider. The best SaaS businesses solve problems people are already spending money or significant effort to work around.
Test your problem statement by asking three questions:
- Is the pain recurring? One-time problems don't sustain subscriptions.
- Is the audience findable? You need to be able to reach these people through specific channels.
- Are they already paying for alternatives? Willingness to pay is the strongest validation signal.
If you can't answer "yes" to at least two of these, iterate on the problem statement before moving forward.
🔍 Step 2: Research Your Competitors
Competition is a good sign — it proves a market exists. What matters is whether you can differentiate.
Search for two types:
- Direct competitors — same solution to the same problem
- Indirect competitors — different solution to the same problem
Study their pricing, features, and customer reviews. Pay special attention to recurring complaints in reviews, Reddit threads, and community forums. Those complaints are gaps you can exploit.
Where to Find Competitor Intelligence
| Source | What to look for |
|---|---|
| G2 and Capterra | Feature comparisons, verified reviews |
| Reddit and Indie Hackers | Unfiltered complaints, feature requests |
| Product Hunt | Launch positioning, early user feedback |
| Twitter/X | Real-time sentiment, power user opinions |
| Competitor pricing pages | Pricing models, tier structures, what's gated |
Tools like VibeGen can accelerate this process — running automated market research that pulls competitor data, analyzes pricing models, and identifies underserved segments. Work that otherwise takes days of manual searching.
When we validated VibeGen's concept, we found that existing AI idea generators focused on brainstorming but stopped short of producing actionable development documents. That gap — from idea to implementation-ready PRD — became our core differentiator.
📊 Step 3: Size the Market (Bottom-Up)
You need to know whether enough people have this problem to sustain a business.
The formula:
| Metric | How to estimate |
|---|---|
| TAM (Total Addressable Market) | # of potential users × annual revenue per user |
| SAM (Serviceable Addressable Market) | The slice you can realistically reach |
| Target revenue | SAM × expected conversion rate |
If SAM is under $1M annually, you're looking at a lifestyle business at best. That's fine if it matches your goals — but know what you're building toward.
Skip the top-down estimates. "The project management market is $7B" is meaningless for a solo founder. Go bottom-up with real numbers.
How to Estimate Bottom-Up
Here's a practical approach:
- Find a proxy metric. How many people search for related terms? Use Google Trends or keyword research tools.
- Count communities. How many members in relevant subreddits, Discord servers, or forums?
- Check competitor traction. Do competitors share revenue numbers on Indie Hackers or Open Startups?
- Apply conversion math. If 10,000 people have the problem, and 2% would pay $20/month, that's $48K ARR. Is that enough for you?
For VibeGen, we estimated bottom-up: roughly 500,000 active indie hackers worldwide (based on Indie Hackers community size, relevant subreddits, and Twitter developer communities). Even capturing 0.1% at $12-29/month made the unit economics viable.

🎯 Step 4: Identify Your Target Customer
"Everyone who needs project management" is not a target customer. Get specific.
Define your ideal customer profile (ICP):
- Job role and daily workflow
- Company size and budget
- Buying behavior — do they pay for tools already?
- Where they hang out online
Then talk to 5-10 people who fit your ICP. Ask about their workflow, frustrations, and what they've tried before. Don't pitch your idea — just listen.
If you can't find anyone who cares about the problem, that's your answer.
Questions That Actually Reveal Demand
Avoid leading questions like "Would you use a tool that does X?" Instead, ask:
- "Walk me through how you handled [problem] last time it came up."
- "What's the most frustrating part of that process?"
- "Have you tried any tools or workarounds? What worked and what didn't?"
- "If you could wave a magic wand, what would change about this workflow?"
- "How much time/money does this problem cost you per month?"
The Mom Test by Rob Fitzpatrick is the definitive guide on asking questions that produce honest answers instead of polite encouragement. Worth reading before any customer conversation.
💎 Step 5: Craft Your Value Proposition
Your value proposition bridges the problem and your solution. It answers one question: why should someone choose you over alternatives (including doing nothing)?
Use this template:
"We help [target customer] to [solve specific problem] by [your unique approach], unlike [alternatives] which [their limitation]."
If your unique approach is "we have a nicer UI," that's weak differentiation. Strong value propositions center on outcomes: faster results, lower cost, less complexity, or access to something competitors don't offer.
Types of Defensible Differentiation
| Type | Example | Strength |
|---|---|---|
| Speed | "Get a PRD in 10 minutes, not 10 hours" | Strong if measurable |
| Integration | "Output feeds directly into AI coding tools" | Strong if workflow matters |
| Data advantage | "Trained on 10,000 real SaaS launches" | Very strong, hard to copy |
| Audience focus | "Built specifically for solo indie hackers" | Moderate, easy to copy |
| Price | "Free tier with no credit card" | Weak alone, strong combined |
For VibeGen, the differentiator is structured output designed for AI coding assistants — not just brainstorming, but producing PRDs and task lists that you can feed directly into Claude Code or Cursor and start building. That bridges the gap between planning and vibe coding.
🧪 Step 6: Get Simulated Feedback
Traditional validation says to pre-sell or run a landing page test. Those methods work, but they take weeks and require an audience you might not have yet.
There's a faster first pass: simulated customer feedback.
VibeGen runs your concept through simulated customer panels — representing personas like early adopters, budget-conscious buyers, and enterprise decision-makers. You get structured feedback on:
- Willingness to pay — and at what price point
- Top objections — what would stop them from buying
- Feature priorities — what they care about most
This isn't a replacement for real customer conversations. But it compresses weeks of initial research into minutes and helps you refine your pitch before approaching real prospects.
Validating with Real Signals (After Simulated Feedback)
Once simulated feedback refines your concept, validate with real market signals:
- Landing page test. Build a simple page describing the product. Drive traffic via relevant communities. Measure email signups.
- "Concierge" MVP. Deliver the service manually for 5-10 customers before building software. If they pay for the manual version, they'll pay for the automated one.
- Pre-sale. Offer lifetime deals or early-bird pricing before the product exists. Revenue is the strongest validation signal.
The key is layering these approaches — simulated feedback first (hours), then landing page (days), then pre-sales (weeks). Each layer increases confidence while reducing risk.
📋 Step 7: Write the MVP Spec (Not the MVP)
Before you build anything, write down exactly what the minimum viable product looks like. Not a vague feature list — a structured PRD that defines:
- The core user flow (one path, end to end)
- Must-have features (3-5, no more)
- What you're explicitly leaving out
A good MVP spec prevents scope creep, the silent killer of indie projects. It forces you to commit to a first version small enough to ship in weeks, not months.
The "Not Building" List
This is the most important part of an MVP spec. Explicitly list features you're choosing to defer:
- "No mobile app — responsive web only"
- "No team features — single user only"
- "No custom domains — vibegen.eu subdomain only"
- "No integrations — export as Markdown only"
Writing the "not building" list prevents feature creep before it starts. Every feature request during development gets checked against this list.
If writing the spec feels overwhelming, tools like VibeGen can generate a structured PRD from your validated idea — complete with user stories, technical considerations, and a phased task list. Our walkthrough on going from idea to PRD in 10 minutes shows this process in detail. You can get started and go from idea to PRD in a single session.
Once your PRD is ready, the next question is which tech stack to use. Our indie hacker tech stack guide covers the tools that work best for solo founders — and which ones pair well with vibe coding workflows.

🗺️ The Full Sequence
| Step | Focus | Key Question |
|---|---|---|
| 1 | Define the problem | One sentence, measurable pain |
| 2 | Research competitors | Where are the gaps? |
| 3 | Size the market | Bottom-up, realistic numbers |
| 4 | Identify your customer | Narrow ICP, real conversations |
| 5 | Craft value proposition | Outcome-focused differentiation |
| 6 | Get feedback | Simulated or real, before you build |
| 7 | Write the spec | PRD that constrains scope |
If your idea survives all seven steps, you have something worth building. If it doesn't, you saved yourself months of wasted effort — and you can run the next idea through the same process in a fraction of the time.
⏱️ How Long Should Validation Take?
A common objection: "Validation takes too long — I just want to build." Here's a realistic timeline:
| Step | Time Investment |
|---|---|
| Problem definition | 1-2 hours |
| Competitor research | 2-4 hours (or minutes with automated tools) |
| Market sizing | 1-2 hours |
| Customer interviews (5-10) | 1-2 weeks |
| Value proposition | 1 hour |
| Simulated feedback | 30 minutes |
| MVP spec / PRD | 2-4 hours (or 10 minutes with VibeGen) |
Total: 1-3 weeks for thorough validation. Compare that to the 2-6 months you'd spend building something nobody wants. The math is clear.
In our experience, the steps that provide the most signal per hour invested are customer interviews (Step 4) and competitor gap analysis (Step 2). If you're short on time, prioritize those.
📌 Key Takeaways
- 35% of startups fail from no market need — validation is the highest-leverage activity you can do before writing code.
- Define the problem in one sentence. If you can't articulate the pain clearly, neither can your customers.
- Competition is good. It proves demand. Focus on finding gaps in competitor offerings.
- Size the market bottom-up. Top-down estimates ("The market is $10B") are meaningless for indie hackers. Count real potential users.
- Talk to real people. Five honest conversations reveal more than weeks of speculation. Use the Mom Test approach.
- Layer your validation. Simulated feedback (hours) → landing page (days) → pre-sales (weeks). Each layer builds confidence.
- Write the MVP spec before the MVP. The "not building" list is as important as the feature list.
- Validation takes 1-3 weeks. Building the wrong product takes 2-6 months. The ROI is obvious.
Bottom Line
The hardest part of building a SaaS is not the code. It's making sure the code solves a problem someone will pay for.
Validate first. Build second.
Ready to validate your next idea? Check out VibeGen's pricing and run your concept through automated market research, customer validation, and PRD generation — all in one place.
