How to validate a SaaS idea cheaply

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

Validating a SaaS idea cheaply means collecting evidence that a specific person will pay to solve a specific problem — before you write a line of the actual product. "People said they'd use it" is not evidence; someone pre-paying, putting down a deposit, or reaching for their card is. Do this in a matter of weeks with conversations, a landing page, and maybe a manual version of the service — not months, and not a built app.

Disclosure: SoleOS publishes this guide, and we sell portfolio-tracking software to founders past this stage, so read the framing accordingly. You don't need SoleOS to validate an idea — a notebook, a landing page, and 20 phone calls do the job; if you're pre-revenue, spend money on ads or pre-order incentives, not tooling.

Validation is a payment signal, not an opinion poll

The biggest trap in idea validation is collecting agreement instead of commitment. "That's a great idea," "I'd totally use that," "yeah, I have that problem too" — these feel like green lights, and none of them predict whether anyone will pay. People are polite, especially to founders they like. The only question that matters is whether someone will trade money, or something that costs them real effort, for what you're proposing to build. Everything else is market research, not validation.

This matters more the more products you run. Testing a third or fourth idea alongside shipped apps, it's tempting to greenlight on vibes because you're moving fast — then spend two months building something six people liked in a Slack thread. The cheap tests below convert "liked it" into "paid for it" before that time gets spent.

Problem validation vs. solution validation

Before testing whether people will pay for your solution, confirm the problem is painful enough that people already spend time or money on it. Ask about current behavior: what do they use today, what have they tried, what does it cost them when it happens. If nobody has ever tried to solve this — no spreadsheet hack, no competitor, no workaround — that's often a sign the problem isn't painful enough to pay for, not a sign of open water.

Solution validation comes second, only after the problem checks out: will people pay for this specific fix, at this price, delivered this way? A real problem can still fail solution validation because your approach is wrong or too expensive. Keep these as separate questions — conflating them is how founders end up with "everyone agrees this is a real problem" as false confidence in their specific product.

Talk to about 20 people in a niche you can actually reach

Twenty conversations is enough to see a pattern without taking months. The niche matters more than the count: pick a group specific enough that you can find them — a subreddit, a Slack community, a list of companies with a shared trait, past customers of a related tool — rather than "small business owners" or "developers," which are too broad to reach or learn anything specific from.

Ask about past behavior and specific incidents, not hypotheticals. "Walk me through the last time this happened" beats "would you use a tool that does X" — anyone will answer a hypothetical positively, but specifics about what they actually did and paid are harder to fake enthusiasm for. If you can, end by asking for something concrete: a pre-order, a waitlist email with a stated price, a follow-up demo. Watch who actually follows through.

Cheap tests, and what each one proves

• Landing page + waitlist. Cheapest test, weakest signal alone. It proves curiosity — someone typed their email — but an email costs nothing and proves nothing about paying. Fine as a top-of-funnel filter. Showing a price and tracking click-through is a stronger signal than raw signups.
• Pre-orders or paid waitlist spots. Asking for money (even a small, refundable deposit) before the product exists is a real test, because it costs the person something to say yes. A handful of real pre-orders from your target niche beats a hundred free signups.
• Concierge or manual MVP. You deliver the outcome by hand — spreadsheets, your own labor standing in for the software — while charging close to what you'd eventually charge. Slow and deliberately unscalable: it proves people pay for the outcome, and teaches you the real workflow before you automate the wrong one.
• Smoke test / fake door. A landing page or ad presenting the finished-sounding product, routing clicks to "coming soon" instead of checkout. It measures real click-through and purchase intent under real conditions without you building anything. Good complement to interviews because it tests strangers, not people you talked into a call.

None of these alone is proof enough to build on — layering two or three is what moves you from "I think people want this" to "I have evidence people will pay for this."

The strongest signal, and the false positives to watch for

Nothing beats someone pre-paying, or reaching for their card before you've asked. If a person asks "can I pay you now" unprompted, that's a stronger signal than a dozen enthusiastic conversations. Treat unprompted requests to pay as the gold standard and everything else as a proxy for it.

Watch for two false positives. First, friends, family, and your existing network: their enthusiasm is genuine but unreliable — they're evaluating you, not the product. Get outside that circle before you trust the signal. Second, vague enthusiasm without specifics: "I'd definitely use that," said fast with no follow-up questions, is usually politeness. Compare it against someone asking "does it integrate with X," "what does it cost," "when can I start" — those questions mean they've actually pictured using it.

Time-box the whole thing

Set a hard window — a few weeks is enough — and a decision date before you start, plus the specific evidence that would make you proceed (a set number of pre-orders from the niche, or a concierge client who pays for a second month). Validation has no natural stopping point; you can always talk to five more people or run the landing page one more week. Without a deadline and a written bar for "enough," validation quietly becomes procrastination on the harder work of building and selling.

When you've validated enough to build

You've validated enough when you have real payment commitments — pre-orders, a paying concierge client, a deposit — from people inside the niche you defined, not your network, and when you can describe the problem back to a stranger in their own words. At that point, build the thinnest version that delivers the core outcome you tested, and keep selling it manually alongside the build rather than disappearing to code for months. For what comes right after — turning early payers into recurring revenue — see our guide on getting to your first $100 in MRR, and browse the rest of the Founder Playbook for later stages. When you've validated and shipped and want revenue, traffic, and signups for that product (and the others you run) in one place, the demo and pricing are there — which is later than what this guide covers.

Frequently asked questions

How many people do I actually need to talk to before building?

There's no magic number, but around 20 conversations inside a specific, reachable niche is usually enough to see a repeating pattern — the same complaint, the same workaround, the same "yes I'd pay" or hesitation. What matters more than the count is that they're the actual people you'd sell to, not friends, and that you ask about specific past behavior rather than hypotheticals.

Is a waitlist with a lot of signups a validated idea?

Not on its own. A waitlist signup costs someone nothing more than an email address, so a large list mostly proves the landing page worked, not that anyone will pay. Treat waitlist size as a top-of-funnel number and look for a stronger downstream signal — a stated price with click-through, a pre-order, or people asking when they can pay.

What's the difference between problem validation and solution validation?

Problem validation confirms people genuinely have the pain and already spend time or money working around it. Solution validation confirms people will pay for your specific answer, at your price, in your format. You can have a real, validated problem and still build the wrong solution for it — worth testing as two separate questions, not one.

Can I validate an idea without writing any code?

Yes, and you generally should. Conversations, a landing page, a smoke test, and a manual concierge version of the service can all run without a line of the eventual product. Concierge even lets you charge real money for the outcome while delivering it by hand — often the fastest way to learn whether the value is real before automating it.

How do I avoid false positives from people who are just being nice?

Weight unprompted requests to pay far above verbal enthusiasm, and discount signal from friends, family, or your existing audience, since they're evaluating you rather than the product. Ask about specific past incidents and watch for follow-up questions about price and timeline rather than "would you use this" — people who ask "how much" and "when can I start" are showing real interest; people who just say it sounds great usually are not.