How to validate a SaaS idea as a solo founder (before you build it)
Building the wrong thing is the most expensive mistake a solo founder can make. Here's how to validate a SaaS idea cheaply and fast — before you write a line of code.
TL;DR
To validate a SaaS idea as a solo founder, test demand before you build: put up a simple landing page with a waitlist, run five to ten customer interviews, and try to collect a pre-order or a manual 'concierge' delivery of the value. If people give you their email, their time, or their money, that's a signal to build; if they only give polite encouragement, that's a signal to stop or pivot.
On this page
- Validate before you build — for a solo founder, months spent building the wrong thing is the costliest mistake there is.
- The cheapest validation methods are a landing-page waitlist, five to ten customer interviews, pre-sales, and a manual concierge MVP.
- Real signals cost the customer something: email, time, or money. Compliments and 'that sounds cool' are noise.
- Search for existing demand first — competitors, forum complaints, and search volume prove people already want a solution.
- Time-box validation to two weeks. The goal is a go/stop decision, not a perfect answer.
- Turn each validation finding into a concrete, scored next task so momentum doesn't leak away.
The most expensive thing a solo founder can do is spend three months building a product nobody wants. You don't have a team to absorb the cost, a runway of investor money, or a marketing department to force distribution later. You have your own hours — and those hours are the whole company. That's exactly why validation matters more for you than for a funded startup: you can't afford to be wrong for long. The good news is that validating a SaaS idea is cheaper and faster than most founders think, and you can do almost all of it before writing a single line of code.
Why solo founders must validate before building
Building is seductive because it feels like progress. Code compiles, screens light up, and at the end of a session you can see what you made. Validation feels like the opposite — vague, social, and uncomfortable. So most technical founders skip it, build the thing they already decided to build, and only discover the market's verdict after launch, when the sunk cost is highest and the disappointment is sharpest.
The point of validation is not to prove your idea is good. It's to find out whether it's bad while that discovery is still cheap. A week of talking to potential customers can save you a quarter of building. Reframe it that way and validation stops feeling like a detour and starts feeling like the highest-leverage work you can do.
Start by searching for demand that already exists
Before you run a single interview, spend an afternoon finding out whether anyone is already looking for what you want to build. Existing demand is the strongest early signal there is, and it costs you nothing but attention. If people are actively searching, complaining, and paying for clumsy workarounds, you don't have to create a market — you just have to serve one.
Where to look
- Search terms: use a keyword tool to check whether people search for your problem, and how often. Real search volume means real demand.
- Competitors: existing paid tools are proof of a market, not a reason to quit. If they're ugly, expensive, or bloated, that's your opening.
- Communities: Reddit, Indie Hackers, niche forums, and support subreddits are full of people describing their pain in their own words.
- Reviews: read one- and two-star reviews of adjacent products. Every complaint is a feature someone would pay you to fix.
- Workarounds: if people are duct-taping spreadsheets, Zapier, and manual steps together, they've already told you they'll pay to escape that.
The absence of any existing demand is itself a signal — usually a warning one. 'Nobody else is doing this' occasionally means you found a gap, but far more often it means people tried and there's no money in it. Treat an empty market as a red flag to investigate, not a green field to celebrate.
Cheap ways to validate without building
Once you've confirmed the problem is real, you need to test whether your specific solution earns something from the people who have it. The methods below are ordered roughly from lowest to highest commitment — and the higher the commitment you can extract, the stronger the signal.
Landing page and waitlist
Put up a single page that describes the outcome your product delivers, not its features, and ask for an email. You can build it in an afternoon with a no-code tool. Drive a trickle of relevant traffic to it — a few forum posts, a small ad budget, a comment where your buyers already hang out — and watch the conversion rate. Emails are cheap for visitors to give, so treat them as a weak-but-real signal: enough interest to keep going, not enough on their own to greenlight a build.
Customer interviews
Five to ten honest conversations will teach you more than a hundred survey responses. The trap is that people are polite: ask 'would you use this?' and everyone says yes. Instead, ask about the past, which people can't fake. 'When did you last hit this problem? What did you do about it? What did that cost you? What are you using now, and what do you hate about it?' You're mining for evidence of real pain and real spending, not opinions about your idea.
Compliments are the currency of politeness. Email addresses, calendar time, and money are the currency of validation. Only the second kind counts.
Pre-sales
The strongest validation short of a finished product is someone paying you before it exists. Offer a founding-member discount, a lifetime deal, or a paid pilot, and ask for the card. A pre-order is uncomfortable to request precisely because it's the truest test — money is the one signal nobody gives out of politeness. Even a handful of pre-sales tells you more than a thousand waitlist emails.
The concierge (manual) MVP
Before you automate anything, deliver the value by hand. If your idea is a tool that generates weekly reports, make the reports yourself and email them. If it's a matching service, do the matching in a spreadsheet. You'll learn what customers actually need, whether they'll pay for the outcome, and where the real work is — all without building software. Only automate the parts you've proven people want, and let the manual version fund the automated one.
Signals that mean 'go' vs 'stop'
Validation is only useful if you're honest about what the results mean. The tell is always the same: did the person give up something that cost them? Sort your evidence into signals that count and signals that don't, and let the balance decide.
Go signals
- People hand over email, time, or money without much prompting.
- You hear the same painful problem described unprompted, in the customer's own words, again and again.
- Prospects are already paying for a worse solution or a painful workaround.
- At least one person tries to pre-order or asks when they can start paying.
- Interviewees follow up with you, forward the page to a colleague, or ask to be kept in the loop.
Stop (or rethink) signals
- Enthusiasm that evaporates the moment you ask for a commitment.
- Everyone loves it, but no one has ever spent money or effort on the problem before.
- You have to explain the problem before anyone recognizes it — you're educating a market, not serving one.
- The only people interested are other founders, not your actual buyers.
- A waitlist that fills with sign-ups but produces zero replies when you ask a real question.
Common validation mistakes to avoid
Most failed validation isn't failed because the idea was bad — it's failed because the founder ran the test wrong and read a false positive. Watch for these traps, which are especially easy to fall into when you're validating alone with no one to check your bias.
- Asking leading questions. 'Wouldn't it be great if...' invites a yes. Ask about past behavior instead of future intentions.
- Validating with friends. They want to encourage you, so their feedback is worthless as data. Talk to strangers who have the problem.
- Building 'just a small version' to test. A small build is still a build — it's procrastination dressed as validation.
- Confusing interest with demand. A signup costs nothing; a payment costs something. Weight your evidence accordingly.
- Never asking for money. If money never enters the conversation, you haven't run the only test that reliably predicts a business.
- Moving the goalposts. Decide your go/stop criteria before you start, or you'll rationalize whatever result you secretly wanted.
Keep validation lightweight and time-boxed
Validation can quietly become its own form of procrastination — an endless loop of interviews and landing-page tweaks that let you feel busy without ever committing. Prevent that by time-boxing it. Give yourself two weeks and a target: talk to ten people, put up one page, and try for one pre-sale. At the end, you make a decision — go, stop, or pivot — with the evidence you have, not the evidence you wish you had.
The final piece is turning what you learned into motion. Validation produces a pile of insights — an objection to answer, a feature people begged for, a pricing signal, a pivot to explore — and that pile leaks away if it never becomes concrete work. Convert each finding into a scored next task ranked by impact, so the moment you decide 'go,' you already know the highest-leverage thing to build first. A tool like shipsolo exists to catch exactly those findings and rank them, so your validation flows straight into a prioritized build list instead of a forgotten notes file.
Validating before you build isn't caution — it's leverage. Spend two weeks proving demand and you buy yourself the confidence to spend the next three months building something you already know people want. For a solo founder, that trade is the closest thing there is to a cheat code.
Frequently asked questions
- How do I validate a SaaS idea without building it?
- Test demand with things you can make in a day: a landing page with a waitlist, five to ten customer interviews, and a manual 'concierge' version where you deliver the value by hand. The strongest test is asking for a pre-sale — if someone pays before the product exists, you've validated it. None of these require writing production code.
- How many customer interviews do I need to validate an idea?
- Five to ten focused interviews are usually enough to see a pattern, because you're looking for repeated, unprompted descriptions of the same real pain — not a statistically significant sample. Ask about what people did in the past and what it cost them, not whether they'd use your idea. If the same problem and the same spending keep surfacing, that's your signal.
- What counts as a strong validation signal?
- The strongest signals cost the customer something: money, time, or a genuine commitment. A pre-order beats a waitlist email, a booked interview beats a like, and unprompted repeated complaints beat polite enthusiasm. If someone praises your idea but won't give up anything to have it, treat that as a stop signal, not a go signal.
- How long should idea validation take for a solo founder?
- Time-box it to about two weeks so validation doesn't become procrastination. Set a concrete target upfront — for example, ten interviews, one landing page, and one attempted pre-sale — and commit to making a go, stop, or pivot decision at the end. The goal is a confident decision, not a perfect answer.
- Should I validate an idea if competitors already exist?
- Yes — existing competitors are proof that a market and real money exist, which is a stronger starting point than an empty market. Your job is to validate that a specific underserved slice of that market will switch to you, usually because current tools are too expensive, too complex, or missing something people keep complaining about. An empty market is more often a warning than an opportunity.
Put this into practice
shipsolo turns advice like this into scored tasks for each of your apps.
Try shipsolo freeKeep reading
How solo founders build an AI-assisted shipping workflow
Most solo founders use an AI coding agent for writing code and a separate tool for tracking what to build. The gap between the two is where momentum dies. This guide walks through building a coherent AI-assisted workflow: a ranked task board your agent can read and update, a daily trigger that keeps both in sync, and guardrails that keep you in the driver's seat without babysitting every line.
🗓️The 20-minute weekly review system for solo founders
Without a weekly reset, solo founders drift: they ship the wrong things, lose track of milestones, and arrive at Friday wondering where the week went. A 20-minute weekly review fixes all three, and this article shows you exactly how to run it.