The most expensive way to validate a SaaS idea is to build it. Every week, founders pour months of savings and energy into product they didn't need to write, because validating ideas with code is the comfort zone. Building feels like progress; talking to strangers about a problem they may or may not have feels uncomfortable. So we build first. And often we discover, months in, what a few cheap conversations would have told us in a fortnight. Here's how to validate properly — before a single line of code.
What you're actually trying to validate
"Validation" gets used loosely. There are three different things you might mean, and they don't all need code:
- The problem is real. People actually experience the pain, frequently, and would pay (or already pay) for relief.
- Your solution is plausible. What you're proposing genuinely solves the problem in a way they'd adopt.
- There's a viable business at the intersection — pricing, channel, repeatability.
The mistake is jumping straight to #2 — building a prototype — when you haven't validated #1. Code can never confirm a real problem. Only people can.
The conversations that move the needle
Most "founder interviews" go badly because they're really pitches with question marks at the end. ("Wouldn't you love a tool that does X?") What you want instead is a conversation about the current state of the world, with no mention of your idea.
A useful structure:
- What does your day/workflow look like around X?
- What's the most painful part of that?
- What have you tried to fix it?
- What did you pay for, and what did it not do?
- If a tool solved this completely, what would your life look like?
You're hunting for two things: people who already feel the pain enough to spend time or money on it, and the specific words they use to describe it. The second is gold — those words become your landing page, your onboarding copy, your sales motion.
A rough target: ten conversations before you decide either way. Five isn't enough; you'll see what you want to see. Twenty is overkill at this stage.
The signals that mean "go"
You're not looking for "that's a great idea." Anyone polite says that. You're looking for:
- Active workarounds. They already do this thing manually, with a spreadsheet, with three tools duct-taped together. That workaround is the strongest possible signal — they're already paying in time.
- Money already on the table. They pay for a worse version. They have a budget for the category. They've tried a competitor.
- A specific moment of pain they can describe — "last Tuesday, I spent four hours doing X by hand because no tool does this." Vague pain doesn't get paid for.
- A "when can I see it?" unprompted. People aren't usually that direct; when they are, listen.
If you can't find any of these in ten conversations, that's also a result. Either the problem isn't as universal as you thought, or you're talking to the wrong people. Both are useful to know before you spend six months building.
Cheap tests that beat building
There are at least four ways to test a SaaS idea more cheaply than coding it:
1. A landing page with an honest offer
Build a single page describing the problem, the solution, and a single CTA — "join the waitlist," "request a demo," "buy for $X" (you can refund if you don't ship). Drive a small amount of targeted traffic to it. Sign-up rate is information. Signups with notes about their specific pain is much better information.
A landing page won't tell you the product is right. It will tell you whether the positioning resonates with the people you'd need to sell to.
2. A pre-sale or letter of intent
Nothing focuses the mind like asking for money — or a signed commitment — before the product exists. If you can pre-sell five seats at your target price, you've validated more than any survey. If you can't, the price is wrong, the audience is wrong, or the problem is softer than you thought.
3. A concierge MVP
For SaaS that automates a workflow, the highest-fidelity validation is to do the workflow manually for paying customers first. They don't need to know it's manual. You'll learn more about the real workflow in two weeks of doing it by hand than you'd learn in three months of building software around your assumptions.
4. A no-code prototype
If you genuinely need to show the workflow before people will commit, build it in no-code (Airtable, Bubble, Retool) — not your real stack. The prototype isn't the product; it's a research instrument. You can throw it away once you've learned what you needed to.
What you don't need to do yet
A few things founders do in "validation" that aren't validation:
- Designing the logo and choosing the name — interesting, but doesn't validate anything.
- Picking the tech stack — that decision will happen, but not now.
- Writing the pitch deck — useful when you're raising; premature before you have signal.
- Building a "small MVP" that takes three months — that's not validation, that's just a build. Real validation should be measured in weeks, not quarters.
When you're ready to build
You're ready to build the real V1 when you can answer all three honestly:
- You can describe the problem in the user's own words. Not your words. Theirs.
- You can name the smallest version of the product that gets a user from pain to relief.
- You have at least a few people who've signalled commitment — money, time, signed letter, anything stronger than "looks cool."
When you can, the build itself becomes a different kind of project — focused, urgent, well-aimed. That's the build that ships in 90 days instead of dragging out for a year. If you want a walk-through of that next stage, our post on going from idea to launch picks up where this one ends.
We've seen both versions
We've built SaaS products with founders who validated rigorously, and with founders who didn't. The first group ships faster, lands earlier customers, and pivots less. The second group builds two products by accident. Discipline at this stage doesn't slow you down — it's what makes the build, when it happens, count.
We help founders go from validated idea to live SaaS — including the web app build and the engineering team behind it. If you're sitting on a SaaS idea and not sure whether it's ready to build, book a call. We'll give you a straight read — including, sometimes, "this isn't ready yet."
