How to validate a SaaS idea before writing code

The single most expensive mistake a non-technical founder makes is building before selling. Six months of nights and weekends, a few thousand dollars on a developer, a polished landing page — and then the launch lands on an audience that nods politely and never types a card number. Almost every "we built it and they didn't come" story traces back to the same root cause: the founder validated the wrong thing. They validated curiosity. They needed to validate willingness-to-pay. Those are not the same signal, and the gap between them is where most SaaS attempts die.

This is the version of "how to validate a SaaS idea" that skips the lean-startup-101 advice and goes through what actually predicts paid demand. What customer interviews can and cannot tell you. Why waitlist signups are usually a vanity metric. The difference between "I'd use this" and "I'd pay $50 for this". How concierge MVPs work when you have no product. And — the cleanest validation signal on the internet — pre-orders, where someone hands you money before the thing exists. Once the willingness-to-pay signal is clear and you're staring at the question of what to do next on a weekday morning, the 90-day employee-to-SaaS-owner transition plan is the post that picks up where this one ends. If a pre-order test on a short-link or QR niche is the validation step you settle on, the Linked.Codes lifetime plan is the engine you can resell once the pre-orders confirm willingness-to-pay — and the getting-started docs cover the signup-to-first-link path you'll be walking that first customer through.

What "validating a SaaS idea" actually means#

Validating a SaaS idea means proving — before you build the product — that a specific group of people will pay a specific price for a thing that solves a specific problem. The word "pay" is doing most of the work in that sentence. If your validation method produces evidence that people want it without producing evidence that they'll pay for it, you haven't validated anything. You've collected applause.

The four methods worth using, ranked roughly by signal strength: customer interviews, landing-page tests, paid concierge MVPs, and pre-orders. Each is useful at a different stage and each lies in a different way. The art of validation is knowing which method gives you trustworthy data at the phase you're in.

Method one — customer interviews, and when they lie#

The first move on most idea-validation playbooks is "talk to ten potential customers". This is good advice carried out badly almost everywhere. The trap: interviews tell you what people say about hypothetical futures, which is famously different from what they do in real ones. Behavioural economists have a name for this — the say-do gap — and it's enormous. The University of Cambridge's Behaviour and Health Research Unit summarised dozens of studies showing self-reported intentions correlate with actual behaviour at roughly 0.3 — meaning intention explains less than 10% of the variance in what people actually do. Most of what an interview captures is hope.

The interview format that works is the one popularised in "The Mom Test" by Rob Fitzpatrick. The mechanics: ask only about the past, never about the future. "Tell me about the last time you needed to send a tracked link to a client" is useful. "Would you use a tool that tracks links?" is useless. The first surfaces a real story with real friction. The second surfaces a polite hypothetical. Every question that starts with "would" or "could" or "do you think you might" is producing fiction, not evidence.

The other thing interviews do badly: validate price. People will tell you a hypothetical price is reasonable when you sketch a product on a napkin; the same people will refuse to pay it when an invoice arrives. Interviews are useful for confirming the problem exists and naming the workflow. They are useless for confirming someone will pay a specific number.

Method two — landing-page tests and the email-signup illusion#

The standard playbook: stand up a one-page site that describes the product, drive paid traffic to it, count email signups. If the conversion rate is above some threshold, the idea is "validated".

The problem: an email signup is approximately free for the user. Typing an address and clicking a button costs nothing. The signal it carries — "this headline is curious enough to give an email to" — is information about your headline, not about your product. Plenty of people who give an email never open the launch email three months later. Y Combinator's startup school content makes this point repeatedly: an email list is "interest", not "demand". The conversion from email to paying customer at launch is, in most cases, between 1% and 5%.

The fix is to make the landing-page test cost the visitor something more than an email. Two refinements:

Show the price. A landing page that exposes the price — "$49/month" or "$299 one-time" — and asks the visitor to click "Start trial" or "Notify me at launch" filters the audience by price tolerance, not by headline curiosity. The bar to click goes up. The signal goes up with it.

Use a fake-checkout flow. Build the landing page with a real "Buy now" button. The button leads to a page that says "We're launching in six weeks — drop your email and we'll honour today's price when we open". The visitor has to click the buy button to find that out. That click is a stronger signal than an email box. The percentage of visitors who do it is roughly 1/10th of the email-signup rate — and that 1/10th is meaningfully more likely to convert at launch.

The trap on landing pages is the same as on interviews: it's possible to declare "validated" on the wrong metric. A 4% email-signup rate is not validation. A 0.4% click-to-buy rate from a clearly-priced landing page is closer to it. Different numbers, different methods, very different conclusions.

Method three — the paid concierge MVP#

This is the single most under-rated validation method on the internet. The concierge MVP is the version where you deliver the product manually, by hand, to a small number of paying customers, before you build any of it.

A concrete example: you want to build a SaaS that gives small e-commerce stores a weekly report on their slow-converting checkout pages. The concierge version is you, in a spreadsheet, manually pulling Stripe and Google Analytics data, writing a Loom video walking through the findings, and emailing it to the customer every Tuesday. You charge $99/month. You sell it to five customers. Nothing about that flow is software. Every part of it is a service. The validation is that five customers are paying $99/month for the outcome — which is the only thing they were ever going to pay for.

Why this method beats every other one: the customer pays real money for a real result. There is no hypothetical anywhere in the loop. If five people pay, the demand is real. If two people pay and three refund, the demand is weaker than you thought. Either way, the signal is unambiguous — because it's denominated in dollars.

The concierge method also teaches you what the product should be in a way no interview ever could. The first month, you'll notice the customers ignore three of the metrics you put in the report and obsess over one. That obsessed-over metric is the actual product. Build software around that. Throw the rest away. This kind of feedback only appears when someone has paid — free users politely consume everything and tell you nothing useful.

The first 100 customers post from Y Combinator's startup school library walks through dozens of examples of founders who started concierge and only built software once the manual version was making real revenue. It's a recurring pattern not because it's clever, but because it's the cheapest way to learn what the customer actually values.

The friction with concierge: it doesn't scale, by design. You can run it for ten customers. You cannot run it for a hundred. The model breaks somewhere between fifteen and twenty-five customers depending on how labour-intensive each delivery is. That's also when you have enough signal to start building real software — and enough revenue to fund the build. The shape of the path is described in detail in the agency-service-to-SaaS leap breakdown, which is essentially the concierge-MVP path extended over a longer horizon: validate by selling services first, productise once the template is undeniable.

Method four — pre-orders, the cleanest signal#

The strongest validation signal short of a working product is a pre-order — a customer paying you, in full or in deposit, before the thing exists. The hardware crowdfunding world has run this experiment thousands of times on Kickstarter and Indiegogo. SaaS founders run it too, just less visibly: "lifetime deals" sold from a coming-soon page, founder-tier discounts pre-launch, six-month subscriptions paid upfront for software that ships in three months.

Pre-orders work because they collapse every form of self-deception. The visitor either pulls out a card or doesn't. There's no email-to-customer leakage to model, no interview-to-purchase friction to estimate, no concierge labour to subsidise the price. The money either arrives or it doesn't. That's the entire signal.

Most validation playbooks skip pre-orders because they feel risky. The fear: what if a hundred people pay and I can't deliver? The honest answer: that's the good problem, and it almost never happens. The realistic outcome on a first attempt is that two or three people pre-order out of a hundred who visit. Three pre-orders at $99 is $297 of validation that beats every interview transcript you'll ever write. If the number is zero, the idea isn't ready — and you've saved yourself six months of build time.

A few rules to make pre-orders honest: state a delivery date you'll hit, offer refunds with one click, and discount the pre-order price meaningfully (20–40%) against the eventual launch price. The discount is the early-adopter premium — they're carrying risk you're not. Without it, the offer is just a regular sale with a wait. Stripe Atlas publishes a useful primer on collecting pre-launch payments without crossing into securities-law territory; the short version is that a pre-order for a deliverable product is fine, equity-like promises are not. Linking through there is worth the ten minutes before you set up the page.

Why "would you use this" is the worst question in validation#

The single most common question in founder-led validation is some variant of "would you use this?" It's also the one that lies most reliably. A few reasons.

People answer "would you use this" the way they answer "would you go to my birthday party" — politely, vaguely, in a way that protects the relationship. Saying "no" feels rude. Saying "yes" costs nothing. So almost everyone says yes. The Boomtown Accelerator at the University of Colorado has published interview-transcript analysis showing that "would-you" questions produce yes rates above 70% even when the eventual purchase rate at launch is under 5%. The yes rate is essentially noise.

The fix is to replace every "would you use this" with a question that has a cost. Three variants in increasing order of signal strength:

"What are you using today for this?" — surfaces whether the problem is even real. If the answer is "nothing, I haven't thought about it", the problem doesn't have a budget line in the customer's head yet. Hard to sell into that.

"What did you do the last time you ran into this?" — surfaces actual past behaviour, which predicts future behaviour roughly ten times better than stated intent.

"Would you pay $50 a month for this?" — and watch the face. The polite "would you use it" yes evaporates when a real number lands. Half the people who said yes at the abstract level will hedge here. The other half is your audience. Better still, follow it with: "Here's my Stripe link, would you put it on a card right now?". That question — terrifying to ask — produces real validation in a single sentence.

The "$50" version of the question works for two reasons. First, $50 is high enough to matter — it's the price of dinner — but low enough that a yes is plausibly honest. Second, naming a number forces the customer to think about their willingness-to-pay budget, which is a different mental compartment than their willingness-to-have-a-nice-conversation budget. The number does the work of separating signal from politeness.

Method picker — your situation, your method#

The picker is the structural answer. The deeper truth is that most non-technical founders end up running two methods in sequence: past-tense interviews to confirm the problem is real, then a concierge MVP or pre-order page to confirm someone will pay. The landing-page ad-test is mostly for founders who can't reach the customer directly — which, if you've spent thirty seconds finding the right LinkedIn group or Slack community, is usually a smaller fraction of cases than it feels like.

What about validating a SaaS idea on top of a service business#

Two paths sit alongside the methods above and are worth naming, because both are validation strategies in their own right. The first is the agency or service business that productises a delivery template after running it manually for fifty clients. By the time you've done the same workflow fifty times, you've validated the demand fifty times, and the only thing left to test is whether external customers will self-serve. The agency-service-to-SaaS leap walks through that timing in detail — the short version is that fifty manual deliveries beats fifty interviews on every dimension.

The second is the "alternative path" that sits below the SaaS-founder hierarchy entirely. A few of the side hustle ideas for non-developers — local lead generation, bookkeeping, whitelabel reseller arrangements — are themselves validation tools. You run the business, see the demand from a different angle, and only build software later when you know exactly what feature would 10x your output. Many strong SaaS ideas start as "I needed this for my own client work" — that's a concierge MVP run on yourself.

Once you do validate and decide to build (or license, or resell), the path forward is mostly volume and patience. The zero-to-$5k-MRR-on-a-single-tool breakdown covers the customer-count and churn math for the eighteen to twenty-four months that follow validation. The intermediate checkpoint — the first $1,000 MRR and which non-developer paths actually reach it — is where most operators discover whether the path they picked matches the asset they can actually build. Validation tells you the destination is real. The MRR math tells you how long the walk is.

How non-technical founders specifically should validate#

A few practical notes for founders who can't or won't write code.

Don't validate by hiring a developer. The single most common failure mode is paying $5,000 to $30,000 to build the MVP, then trying to validate post-launch. The build is the most expensive validation method. Run interviews, concierge, and pre-orders first. Hire the developer only after at least one of those methods produces a paying customer.

Don't try to skip validation by buying or licensing software. The buy-vs-build whitelabel SaaS path is faster and cheaper than a from-scratch build, but it doesn't skip the validation step. A licensed platform with no customers is still a $0/month business. Run the same concierge or pre-order steps with the licensed tool as you would with custom-built software. The platform is the delivery layer, not the validation.

Use no-code where it helps. A pre-order page on Carrd or Webflow is fine. A concierge delivery that runs on Notion and Loom is fine. A landing-page ad test with a Stripe payment link is fine. The point of validation is the signal — paying customers — not the polish of the tooling.

Talk to people. Real ones. The single largest predictor of a SaaS founder's success in the first year is the number of customer conversations they have per week. Anywhere from five to twenty. People who do this don't get blindsided by demand that wasn't there. People who don't do this build for an imagined audience and meet the real one at launch.

The validation discipline isn't a phase. It runs forever — every new feature, every price change, every adjacent product is a new validation question. Founders who get good at it ship things that earn money. Founders who skip it ship things that don't.