How to Validate a SaaS Idea Before Building: 7 Signals That Beat a Landing Page (2026)

A landing page with an email capture form tells you that people are curious. It never tells you they will pay. If you want to know whether a SaaS idea is worth building, you need signals that survive contact with a price tag, not a signup form.

Why Most "Validation" Proves Nothing

Curiosity vs. commitment: the signals that actually predict revenue

Most first time founders confuse interest with intent. A stranger clicking "notify me" costs them nothing and commits them to nothing. Real validation requires the buyer to give up something scarce: money, a signature, or their own time spent doing the workaround you're proposing to replace. Those three currencies, cash, contract, and calendar, are the only things that reliably predict whether someone will actually adopt and pay for what you build.

The landing-page trap and vanity metrics

The classic playbook, ship a landing page, run some ads, count signups, optimizes for a metric that has almost no relationship to willingness to pay. Email addresses are free. Waitlist joins are free. Even a Product Hunt upvote is free. Founders who treat these as validation end up building for an audience that was never going to convert, then wonder why launch day converts at a fraction of a percent. Traffic and signups measure curiosity about a headline, not demand for a product.

What a real validation gate looks like (pass/fail, not "interesting")

A validation gate should give you a binary answer, not a warm feeling. Before you write a line of product code, you should be able to point to real buyers who did one of the following seven things. Treat this as your pass/fail checklist:

1. Paid a deposit or pre-order for a product that does not exist yet.
2. Signed a letter of intent naming a specific price they would pay at launch.
3. Already pay for a workaround (a spreadsheet consultant, a manual service, a competing tool) that proves the budget exists.
4. Used a manual or concierge version of your service more than once without being asked.
5. Referred another buyer to you without being prompted or incentivized.
6. Named the budget owner and confirmed who signs off on the purchase.
7. Agreed to a paid pilot or annual commitment instead of a free trial.

If you cannot point to real instances of at least a few of these, you don't have validation, you have an opinion. The table below shows how each real signal compares to the vanity metric founders mistake it for.

Start With the Problem, Not the Product

Writing a one-sentence problem hypothesis

Before you sketch a single screen, write one sentence: "[Specific buyer] struggles with [specific problem] when [specific situation], and it costs them [time, money, or risk]." If you can't fill in every blank with something concrete, you're not ready to talk to buyers yet, you're still guessing. Vague hypotheses, "small businesses need better software", produce vague interviews and vague products. Paul Graham's essay on how to find startup ideas makes a related point: the strongest ideas tend to come from a problem you or someone close to you actually has, not from a brainstorming list.

Finding where your target buyer already complains

Your buyers are already describing this problem somewhere: in niche forums, in industry Slack and Discord communities, in the reviews section of the tool they currently tolerate, in support tickets if you have access to a partner's help desk. Read complaints in their own words before you write your own pitch. The exact phrasing people use unprompted is usually better marketing copy than anything you'll invent, and it tells you whether the pain is acute or mild.

The "painkiller vs. vitamin" test

Painkillers get bought under pressure. Vitamins get bought when there's spare budget and good intentions, which means they get cut first in a downturn. Run every idea through this filter before investing more time.

If your idea scores mostly in the vitamin column, it can still work, but expect a longer sales cycle and lower price tolerance. Painkillers validate faster and pre-sell easier.

Talk to 15 Buyers Without Leading Them

The Mom Test in practice: past behavior over future promises

The core discipline, popularized by The Mom Test, is simple: ask about specific past behavior, never about hypothetical future behavior. "Would you use a tool that does X" always gets a polite yes. "Walk me through the last time you dealt with this problem" gets you the truth, because people are describing something that already happened rather than being polite about your idea. Y Combinator's own guidance on customer conversations, How to Talk to Users, makes the same point: talk about their life, not your idea. Nielsen Norman Group's guidance on user interviews reinforces this for product research generally: ask about specific past tasks, not opinions about the future.

Scripts that surface budget and urgency

A short list of questions that consistently produce useful answers:

• "What are you currently using to solve this, and what does it cost you, in time or money?"
• "When was the last time this problem cost you real money or a real deadline?"
• "Who else on your team deals with this, and who would need to approve buying a fix?"
• "What have you already tried that didn't work, and why did it fail?"
• "If I had a working version today, priced at [X], who signs off on that purchase?"

Fifteen of these conversations, with people who actually match your buyer hypothesis, is usually enough to see a pattern. Fewer than that and you're pattern matching on noise; many more and you're stalling on a decision you already have enough data to make.

Reading disqualifying signals early

Watch for these tells that an interview is not converting to a real prospect: they can't name a specific past incident, only hypotheticals; they have no idea who controls budget; they compliment the idea but change the subject when you mention price; they describe the problem as mildly annoying rather than costly. Any one of these should lower your confidence, and if you hear all of them from most of your fifteen conversations, the idea is not ready, and possibly not painful enough to pay for.

Pre-Sell Before You Build

Charging money as the only real validation

Everything before this point is research. This is the test. Ask for money, a deposit, a pre-order, a signed contract, before the product exists. Steve Blank's framing in Why the Lean Start-Up Changes Everything treats customer development as inseparable from actual sales conversations, not surveys about intent. If you're too uncomfortable to ask for a card number or a signature, that discomfort is worth examining, because it usually means you don't yet believe in the price yourself.

Letters of intent and paid pilots for B2B

Consumer ideas can often pre-sell directly with a deposit or pre-order, and tools like Stripe's Atlas guides walk through the basic mechanics of taking payment before a product ships, so lack of infrastructure is rarely a real excuse. B2B ideas usually move through a letter of intent, a short signed document naming the price, the scope, and an intended start date, or a paid pilot, a scoped, time boxed engagement the buyer pays for, even at a discount. A paid pilot beats an LOI beats a verbal "we'd definitely buy this," in that order, because each step forward requires the buyer to give up more.

How many yeses actually mean "go"

There's no universal number, but a useful rule of thumb: if fewer than a third of well qualified conversations convert to some form of paid commitment, the idea needs a different angle or a different buyer, not more interviews. If closer to half convert, you likely have enough demand to justify building a narrow first version. Track this as a real ratio, not a gut feeling, so you can compare ideas against each other honestly.

Fake the Product: Concierge and Wizard-of-Oz Tests

Delivering the outcome manually before automating

A concierge MVP means you deliver the actual outcome by hand, using spreadsheets, templates, or your own labor, before writing software. It's slower per customer and doesn't scale, which is exactly the point: it lets you learn what the automated version actually needs to do. Paul Graham's essay Do Things That Don't Scale is the canonical case for this approach, and it's still one of the best short arguments for resisting the urge to build before you understand the job.

No-code prototypes that feel real

A wizard-of-oz test looks automated to the customer but is operated by a human behind the scenes, using no-code tools, forms, and manual work to simulate the finished product. The distinction from a pure concierge test is presentation: the buyer believes they're using software, which tests their actual behavior with something resembling the real interface, not just their willingness to work with you directly.

Measuring retention on a manual MVP

The number that matters here isn't satisfaction, it's return usage. Did the buyer come back and ask for the manual service again without prompting? Did they ask you to expand scope, or add a second use case? Retention on a clunky manual process is a far stronger predictor of retention on a polished product than any survey score, because it reflects a real decision to keep paying attention and, ideally, keep paying.

Your Next Step: Run a 2-Week Validation Sprint

The day-by-day sprint checklist

You can compress most of this into two weeks if you work in a fixed order:

• Days 1 to 2: Write the one-sentence problem hypothesis and identify where your buyer already complains.
• Days 3 to 7: Run 15 Mom Test style interviews, tracking budget and urgency signals for each.
• Days 8 to 10: Build a concierge or wizard-of-oz version for the three most promising prospects.
• Days 11 to 13: Ask for a deposit, LOI, or paid pilot from everyone who used the manual version.
• Day 14: Score the results against your kill criteria and decide: build, pivot, or kill.

If you want a more structured curriculum to work through alongside this sprint, Y Combinator's Startup School covers a similar sequencing of problem discovery, customer conversations, and early sales in more depth.

Explore the carbonapps.com portfolio for build-ready examples

If your two-week sprint produces a clear "go," the next question is how fast you can get from validated demand to a working product without over scoping the first release. That's the exact problem we work on with founders, and it's worth seeing how it plays out across different kinds of SaaS ideas before you commit to a build timeline.

Booking a validation teardown

If you want a second set of eyes on your interview notes, your pre-sell numbers, or your kill criteria before you commit engineering time, that's a conversation worth having early rather than after months of building. Bring your fifteen conversations and whatever pre-sell commitments you've collected, and it's usually a fast conversation.

Set Kill Criteria Before You Start

Defining your "stop" number in advance

Decide, before you run a single interview, what result would make you walk away. Examples: fewer than 3 of 15 buyers describe the problem as costly; zero pre-sell commitments after asking at least 10 qualified prospects; no one can name a budget owner. Write the number down where you can't quietly revise it later. The whole point of a kill criterion is that it's set before you have an emotional stake in a specific answer.

Sunk-cost traps founders fall into

The longer you spend on an idea, the harder it becomes to hear disconfirming evidence honestly. Common traps: reinterpreting a lukewarm "maybe" as a yes, discounting a no because "they're not the real target customer," or deciding you just need to interview five more people after the data already answered the question. If you notice yourself moving the goalposts, that's usually a sign the original goalposts were correct.

When a pivot beats a kill

Not every no is total. If buyers consistently confirm the problem is real and costly but reject your specific solution, price, or format, that's a pivot signal, not a kill signal. The distinction matters: kill the idea when the problem itself turns out not to be painful enough to pay for; pivot the approach when the problem is validated but your proposed fix isn't the one they want.

Scope the Smallest Buildable MVP

From validated demand to a one-feature scope

Once you have real commitments, resist the urge to build everything you discussed in fifteen interviews. Pick the single feature that delivered the outcome in your concierge test, and ship only that. The minimum viable product concept exists precisely to force this discipline: the smallest thing that lets you test the core value proposition with real usage, not a partial version of your full product vision.

What to deliberately leave out

Common items to cut from v1 without guilt: admin dashboards, team roles and permissions, integrations beyond the one your first buyers actually asked for, customization options, and anything you added because it seemed "expected" rather than because a paying buyer asked for it by name.

Choosing build vs. no-code for v1

If your concierge test ran on spreadsheets and templates, ask honestly whether a no-code tool can carry you to your first ten paying customers before you write custom software. Custom code makes sense once you hit a wall a no-code stack genuinely can't clear, not before. Building too early, on unvalidated assumptions, is a more expensive mistake than a slightly rough first version running on borrowed infrastructure.

Frequently Asked Questions

How many customer interviews do I need before validating a SaaS idea? Fifteen well qualified conversations is usually enough to see a real pattern in budget, urgency, and existing workarounds. Fewer than that and you're likely reacting to noise rather than a trend.

Is a landing page with email signups enough to validate demand? No. It measures curiosity about a headline, not willingness to pay. Treat it as a top-of-funnel tool at best, never as proof that people will buy.

How much should I charge in a pre-sell before the product exists? Charge close to what you intend to charge at launch, or at minimum enough that saying yes requires the buyer to feel it. A token dollar amount doesn't test the same commitment a real price does.

What's the difference between a concierge MVP and a wizard-of-oz test? A concierge MVP is openly delivered by a human, the customer knows there's no software yet. A wizard-of-oz test presents something that looks automated while a human operates it behind the scenes, so it also tests the buyer's reaction to the interface itself.

How do I set kill criteria so I don't waste months on a dead idea? Write specific numeric thresholds, minimum interviews confirming pain, minimum pre-sell commitments, before you start collecting data, and treat them as binding once the sprint is done.

Can I validate a SaaS idea without writing any code? Yes. Interviews, letters of intent, deposits, concierge delivery, and no-code prototypes can all produce real validation signals well before any product code exists.

The Bottom Line

Landing pages and surveys are cheap to run and easy to feel good about, which is exactly why they're unreliable. Real validation asks for something the buyer will miss if it's gone: money, a signature, or repeated use of something you built by hand. Run the two-week sprint, hold yourself to kill criteria you wrote before you had a favorite answer, and only then start scoping the smallest version worth building.