CB Insights has run the autopsy on hundreds of dead startups, and the same line keeps showing up. 42% died because there was no market need. They built something nobody wanted.
Most solo founders skip validation. Not because they think it's stupid. Because the standard advice is either academic ("interview 100 customers") or vague ("just build an MVP and see"). Neither of those is something you can actually start on a Tuesday night after work.
This article gives you a 7-step framework that fits in a weekend. Twelve hours, maybe sixteen if you're being thorough. By the end, you'll have a written verdict on your idea. Build, Wait, or Reject. With reasoning you can't quietly walk back two weeks later.
What does it mean to validate a SaaS idea?
Validating a SaaS idea means getting evidence (not intuition) that a defined audience has a specific painful problem, that current solutions fail them, and that they will pay for a better one. It's the difference between "I think this could work" and "three people just paid me to build it."
If you can't name the audience, the pain, the alternatives, and the price, you haven't validated. You've imagined.
This matters because "I think this is a good idea" is a statement about you. Not the market. Markets don't care what you think. They care what they pay for.
Why most SaaS validation advice fails solo founders
Almost every validation framework you'll find online was written for a team that doesn't exist yet. A team with a researcher, a designer, and a budget. You don't have any of those. You have evenings.
It assumes you have a team
Steve Blank's customer development model. The Lean Startup loop. These work. They were also designed for funded teams running build-measure-learn over months. As a solo dev with maybe ten hours a week, you can't run a six-week customer development sprint. You need something tighter.
It treats validation as one-time, not a gate
Here's the thing nobody tells you. Validation is not something you do once at the start and then forget. It's a gate you keep checking against as scope grows. The idea you started with at week one is rarely the idea you're shipping at week ten. If you don't re-validate, you're building on a foundation that already shifted.
It confuses interest with willingness to pay
This is the trap. Someone says "yeah I'd use that" and you treat it like proof. It isn't. Interest is free. Willingness to pay is the only signal that matters, and it's the hardest one to get because it requires asking for actual money or commitment.
The Mom Test (Rob Fitzpatrick's book) covers this in detail. The short version. People lie to spare your feelings. Especially people who like you. Stop asking them.
The 7-step framework to validate a SaaS idea
Here are the seven steps. Read them once, then we'll go deeper.
- Define the exact problem (not the solution)
- Score problem severity (frequency × pain)
- Map existing alternatives (workarounds count)
- Test feasibility (can you ship v1 alone in 4 weeks?)
- Audit your motivation (build-for-self vs. build-for-market)
- Make a written verdict (Build, Wait, or Reject)
- Set a deadline and lock scope
Each step takes 30 to 90 minutes. Total investment is one weekend. If you can't spare a weekend, you can't spare three months building the wrong thing.
Step 1. Define the exact problem (not the solution)
Write the problem in one sentence, with the audience named, before you write a single line about the solution.
Wrong. "An app that helps freelancers track invoices."
Right. "Freelance designers with 3 to 10 active clients lose 4 to 6 hours per month chasing late payments because they don't have a system to send reminders automatically."
The first version is a product description. The second is a problem. You can validate the second. The first is just a feature waiting to be built.
If you can't write your problem statement this way, the rest of the framework won't help. Go back. Re-write it.
Step 2. Score problem severity (frequency × pain)
Two questions. How often does the problem hit? How much does it hurt when it does?
A problem that happens daily and costs the user thirty minutes is a real problem. A problem that happens twice a year and is mildly annoying is a vitamin, not a painkiller. Vitamins don't sell. Painkillers do.
Score each on a 1 to 5 scale. Multiply. Anything below 9 is probably not worth building for. Anything above 15 has commercial potential. The math is rough on purpose. Precision is a trap at this stage.
Step 3. Map existing alternatives (workarounds count)
People do not have your problem and just sit there. They cope. List every way they cope today. Other tools, spreadsheets, Notion templates, hiring an assistant, simply ignoring the problem.
Workarounds count as competitors. Maybe the most dangerous competitors. "We use a Google Sheet and it's fine" is harder to beat than a dedicated competitor with a worse UI, because the Sheet is free and already in their workflow.
If the existing alternatives are genuinely terrible and people are still using them anyway, that's a signal. Either the pain isn't bad enough, or there's something about your audience you don't understand yet.
I rejected one of my own ideas at this exact step. Gaplix was a second-brain tool for filling knowledge gaps as you research. Frequency × pain looked strong. Researchers, writers, and developers hit gaps every day. Then I mapped the workarounds. Notion templates, manual highlights in Readwise, Obsidian backlinks, ChatGPT in a side tab. None of them solved it cleanly. All of them were free, already in the audience's stack, and good enough. I wrote a Reject verdict and dated it. Not because the problem wasn't real, but because the workaround tax was too low for anyone to switch tools. Two months not spent building Gaplix is two months I got back to spend on something with a real switching wedge.
Step 4. Test feasibility (can you ship v1 alone in 4 weeks?)
Most solo founders fail at this step and don't realize it. The question is not "can I build this eventually." It's "can I ship a usable v1 in four weeks of part-time work."
Write down the smallest version that would solve the core problem for one paying user. Strip everything else. No onboarding flows. No team features. No mobile app. No integrations beyond the one critical one. If the smallest version still takes you six months, you have either picked the wrong problem or the wrong scope.
This is also where most solo developers get into scope trouble. The validation feels exciting. The roadmap balloons. By the time you're building, you've added eleven features that have nothing to do with the original problem. Lock scope here. Write down what's in v1 and what's not. Refer back to that list every time you're tempted to add something.
Step 5. Audit your motivation (build-for-self vs. build-for-market)
Be honest with yourself. Why are you building this?
There are two reasonable answers. "I'm building it because I have this problem and want to solve it for myself" is fine. So is "I'm building it because I see a market opportunity and the economics work." Both can lead to good products.
What's not fine is the muddy middle. "I think other people might want this even though I don't have the problem and haven't talked to anyone who does." That's not motivation. That's a wish.
If you're building for yourself, accept that the market might be small and you might not get rich. If you're building for the market, accept that you need to validate hard because you're not the user. Trying to do both badly is how most side projects die.
Quick self-test. Name three people who have this problem, who aren't you, and who you've talked to in the last month. Real names, not "designers in general." If you can't, you're in the muddy middle. Either go talk to three real people this week, or commit to building it for yourself with a small market and stop pretending otherwise.
Step 6. Make a written verdict (Build, Wait, or Reject)
This is the step almost everyone skips, and it's the one that matters most.
After steps 1 through 5, write a verdict. One of three options.
- Build. The problem is real, the audience is reachable, you can ship v1 in time, and you have honest motivation.
- Wait. The idea is interesting but something is missing. Maybe you don't know the audience well enough yet. Maybe you need to validate willingness to pay before committing. Write down what specifically needs to change before this becomes Build.
- Reject. Something fundamental doesn't work. Write down what.
The verdict has to be in writing. Not in your head. In a document with a date on it. This is what stops you from quietly upgrading a Wait to a Build three weeks later when you're bored and your judgement is clouded.
Step 7. Set a deadline and lock scope
If the verdict is Build, set a ship date. Four weeks of part-time work, six at most. Write it down. Tell someone.
Then lock scope. The features in your v1 list at the end of step 4 are the features you ship. Adding anything else requires a written reason. Saving the reason matters. Reading it back two weeks later is humbling.
Most solo developers don't fail at building. They fail at finishing. A locked scope and a real deadline are the two things that turn "I'm working on it" into "I shipped."
Lightweight validation experiments (ranked by signal quality)
The seven steps tell you whether your idea has the shape of something worth building. To know whether the market actually wants it, run experiments. From weakest signal to strongest.
Search volume
Useful as a sanity check. If nobody is searching for the problem you're solving, the problem may not exist or it may be invisible to people who have it. Use Google Keyword Planner or Ahrefs.
But this is the weakest signal. Search volume tells you the problem exists. It tells you nothing about willingness to pay. People search for "free X" all day and never spend a dollar on it.
Reddit and X community signal mining
Find the subreddits or X communities where your target audience hangs out. Read the last six months of posts. Search for your problem in their words. Look for posts that describe the pain.
If you find the same complaint coming up over and over, that's a signal. If you find threads asking "what do you use for X" with twenty conflicting answers, that's a stronger signal. Conflicting answers mean nobody has solved it cleanly.
10 cold problem interviews
Talk to ten people in your target audience who aren't your friends. Don't pitch. Ask about their problem.
The Mom Test rule is simple. Ask about their life and habits, not your idea. "How do you currently handle X?" beats "Would you use a tool that does Y?" every time. They will lie about your idea. They cannot lie about what they did last Tuesday.
Ten interviews is the minimum that gives you actual signal. Five is anecdote. Twenty is a luxury you don't have time for.
Smoke test landing page
Build a landing page. Describe the product. Add an email capture. Drive traffic from communities or paid ads. Target a 15 to 20 percent conversion rate from visit to email.
Below 10 percent and the messaging or the offer is wrong. Or there's no demand. Below 5 percent, walk away.
Pre-orders or paid waitlists
The strongest possible signal short of an actual product. Ask people to put down a small deposit (even $5) to reserve a spot. Most won't. The ones who do are real signal.
A free email signup is interest. A paid pre-order is intent. The gap between those two numbers is the gap between a product and a project.
Common validation mistakes that kill SaaS ideas
These are the traps I've watched (and walked into) the most. Each one looks reasonable from inside the idea. Each one quietly kills the validation.
Asking friends and family. They love you. They will tell you the idea is great. Their feedback is poison. Use them for emotional support, not market data.
Confusing waitlist signups with willingness to pay. A waitlist is a list of people who said yes to a thing that costs nothing. You won't know what fraction will pay until you ask for money. Plan for 10 percent conversion at best.
Skipping validation because "I am the user." This is the most seductive trap. You think you don't need to validate because you have the problem. You still need to validate that other people have it, that they would pay to solve it, and that the way you'd solve it matches how they'd want it solved. Being the user is a starting point. Not a substitute for evidence.
Validating once, never re-validating. The idea you committed to in week one is not the idea you're building in week six. Scope creeps. Features get added. The original problem gets diluted. Re-validate every time you're tempted to add a feature that wasn't on the original v1 list.
When validation says Wait or Reject and how to decide
A verdict of Wait or Reject feels like a loss. It isn't.
The best code is the code you never wrote. Three months not spent building the wrong thing is three months you can spend on the right thing. Or on rest. Or on your day job. All of those beat a finished product nobody wants.
A documented kill is a win. You learned something. You saved months. You have a written record of why this idea didn't work, which means you won't waste another weekend revisiting it next year.
The trick is making the kill stick. If the verdict is Reject, archive the idea somewhere you can read later but not casually browse. If the verdict is Wait, write down the specific condition that would change it to Build. "If I find five people willing to pre-pay" is a real condition. "If I feel more confident later" is not.
If you want a structured way to record verdicts, the SaaS Idea Validation Checklist gives you the seven steps as a printable. One page. Front and back.
From validation to build, the next step
Once validation passes, you have a small window before scope drift sets in. Use it.
The features in your v1 list are the features you ship. Not the features you'd like to add. Not the features that came up in customer interviews and seemed interesting. The original v1 list. Period.
This is where most solo developers fail. A Google Doc with the seven steps and a dated verdict works fine. The point is the discipline. If your discipline is shaky (most of ours is), an app that won't let you start building until the verdict is signed off might be the difference between shipping and not shipping. That's the validation gate workflow inside FoundStep, but the doc version costs nothing and works on a Tuesday night just as well.
Frequently Asked Questions
How long should SaaS validation take?
A weekend if you're focused. Two weekends if you're being thorough. Anything beyond that is procrastination dressed up as research. The seven steps in this article fit into 12 to 16 hours of focused work.
How many people do I need to interview?
Ten is the floor. Five is anecdote. Twenty is research, and you don't have time for that. Ten cold problem interviews from your target audience, ideally not friends, is enough signal to make a Build, Wait, or Reject call.
Do I need a landing page to validate?
Not strictly. You can validate with interviews and community signal alone. But a smoke test landing page with email capture is the cheapest way to get a quantitative signal, and you should probably run one before committing to build.
What if my idea has no competitors?
Suspicious, not encouraging. The most common reason an idea has no competitors is that nobody wants it. Look harder. Check workarounds. People rarely have a problem that no one has tried to solve. If you genuinely find a gap, validate harder, not less.
Can I validate while I build?
You can build while you validate, in the sense that putting up a smoke-test landing page or running interviews while you also code in the evenings is fine. What you cannot do is skip validation, build the whole thing, and then "validate" by launching. That's not validation. That's a gamble with months of your life as the stake.
A weekend, not a quarter
If you're going to validate, validate honestly. Write down the verdict. Read it back to yourself before you start coding. The hardest part of validation isn't the seven steps. It's not quietly walking back the answer when you don't like it.
If you've shipped one already and you're picking the next idea, the shipping playbook covers what comes after validation. If you're trying to figure out whether the build is even financially viable, the startup cost calculator is the next thing to run.
Sources
- The Top 12 Reasons Startups Fail (CB Insights) — cites no market need as the #1 reason at 42%.
- The Mom Test by Rob Fitzpatrick (2013) — interview methodology for honest customer feedback.
- The Four Steps to the Epiphany by Steve Blank — origin of customer development methodology.
I'm a Senior Software Engineer and solo developer. I built FoundStep because I was tired of watching my own side projects die in silence. It forces idea validation, locks scope, and keeps a permanent record of every change so side projects get finished instead of silently abandoned.
If you've killed an idea after running it through a process like this, I'd love to hear about it in the comments. The kill stories are the ones that teach the most.