How to Validate a SaaS Idea Before Coding

You validate a SaaS idea by getting someone to pay, or commit hard, before the product exists. Not a survey. Not a thumbs-up. Money, a signed letter of intent, or a calendar-blocked design-partner call. If nobody will move budget or time for the outcome you describe, the idea is not validated. It is a hope with a landing page.

I’ve shipped products the wrong way around. I have written the code first and gone looking for the buyer second, more than once. Every time, the bill came due later: a working tool that technically solved a problem nobody was paying to solve. The portfolio I run now is built on the opposite reflex. Find the buyer before the build. This post is the version of that lesson I wish someone had handed me earlier.

That distinction is the whole article. Most “validation” advice tests whether people are polite. Real validation tests whether they are willing to be inconvenienced. This post gives you the test I run, the four signals that fool founders, how to pre-sell software that doesn’t exist, and a scorecard that tells you when to build and when to walk. Once the idea clears, the next moves are finding your first paying customer and setting a price they will pay — part of the SaaS Playbooks collection.

Key takeaways

• Validation means someone pays or hard-commits before the product exists — not surveys, likes, or “I’d use that.”
• Four signals fool founders: survey enthusiasm, your own conviction, audience applause, and competitor existence.
• Run five real customer conversations about past behavior (The Mom Test), never a pitch.
• Pre-sell with a design-partner deal, a letter of intent, or a refundable deposit to test real willingness to pay.
• Score the idea on the SaaS Validation Scorecard; build only when it clears, otherwise change the buyer or walk.

Why this matters for solo founders

A funded team can afford to build the wrong thing for six months. You cannot. Your runway is your salary, your savings, and the cost of the products you are not building instead.

The expensive mistake is not a bad idea. It is a bad idea that survives long enough to get coded, deployed, marketed, and supported before the market says no. Validation is the cheapest place to hear “no,” so you want to hear it loudly and early.

Validation means someone pays before the product exists

Rewrite the word “validation” in your head. It does not mean “people think this is a good idea.” It means “people have already started paying for the outcome, even in a crude form.”

There is a ladder of commitment, and only the top three rungs count.

Signal	What it costs the person	Counts as validation?
Likes a tweet / upvotes a post	Nothing	No
Says “I’d totally use that”	Nothing	No
Joins a waitlist with email	5 seconds	Weak
Books a 30-minute call with you	Their time	Moderate
Signs a letter of intent / design-partner agreement	Reputation + intent	Strong
Pays a deposit or pre-pays an annual plan	Money	Strongest

Anything below “books a call” is noise. The reason is simple: people are wired to be encouraging. Telling a hopeful founder “that sounds great” is free and feels kind. The lie is not malicious. It is social lubricant. Your job is to design a test that lubricant cannot pass.

The cleanest test is money. The second cleanest is a commitment that would embarrass them to break. Everything else is people being nice to you.

The four false signals that feel like validation

These four feel like progress. They are how good engineers talk themselves into building for a year with no buyer.

1. Survey enthusiasm. You send a form, 80% say they would pay $20/month, and you start coding. Stated willingness to pay is not revealed willingness to pay. The gap is enormous. A survey respondent risks nothing by saying yes.

2. Your own conviction. “I’d use this every day” is the most dangerous sentence a technical founder says. You are not a representative customer. You are the most biased person in the market. Build for yourself only when you can prove a thousand other people share the exact pain, and you can reach them.

3. Audience applause. A viral tweet about the problem is reach, not demand. People reshare things that make them feel seen. Resharing costs nothing and proves nothing about a purchase.

4. Competitor existence. “There are three companies doing this, so the market is real” is half true. The market may be real and already won. Competitors prove demand exists; they do not prove there is room for you, or that you can reach a buyer cheaper than your price.

The common thread: each signal is free for the other person to give. Validation has to cost them something, or it is theater.

The five-conversation test I run before writing code

Before any code, I want five real conversations with people who have the problem and a budget. Not five surveys. Five conversations where I mostly shut up and they mostly talk about their past, not your idea.

This is The Mom Test by Rob Fitzpatrick applied literally: ask about what they already do and already pay for, never about whether they like your hypothetical. The rule is that you should be able to ask the questions of your mom and still get useful answers, because you are asking about facts, not opinions.

Here is the script I actually use.

1. "Walk me through the last time you dealt with [the problem].
    What did you do, step by step?"
2. "How often does that happen? When did it last cost you real time
    or money?"
3. "What do you use for it today? What did that cost?"
4. "What's annoying about the current way? Have you tried to fix it?"
5. "Who decides whether to pay for a tool like that on your team?"

Five questions, all about the past and present, none about your idea.

Notice what is missing: I never describe my product. The moment you pitch, the person switches from witness to cheerleader, and the data is contaminated. You learn whether the pain is real by how specifically they can describe the last time it hurt. Vague pain (“yeah it’s kind of annoying”) is not a business. Specific pain (“I lost a Thursday to it last month and almost lost a client”) is.

I have to fight my own instinct here. The engineer in me wants to describe the product and watch the person nod. The nod is worthless. Fitzpatrick’s example is the one I keep in mind: ask a parent “would you use an app for X” and they say yes to be supportive; ask “walk me through the last time X happened” and you finally get the truth. The specificity of the answer is the signal. “It’s kind of annoying” is not a business. “I lost a Thursday to it last month and almost lost a client” is.

The tradeoff: five conversations take one to two weeks if you have zero audience, and cold outreach has a low reply rate. That is the cost of buying certainty before you spend three months building. It is the cheapest insurance in software.

How to pre-sell software that doesn’t exist yet

Conversations tell you the pain is real. Pre-selling tells you the pain is worth money to this buyer at your price. That is a different, harder fact, and it is the one that matters.

You do not need a product to pre-sell. You need a credible promise, a price, and a way to take a commitment. Three formats, in rising order of strength.

The design-partner deal. You offer to build the solution with one to three customers in exchange for their time, their feedback, and a commitment to pay once it works. They get influence over the roadmap and an early discount. You get a guaranteed first customer and a tight feedback loop. This is the strongest move for B2B, because it costs them reputation if they flake.

The letter of intent. A short, non-binding note: “If you build X that does Y by roughly Z date, we intend to buy N seats at roughly $P.” It is not a contract. It is a signal with a name attached, and people do not attach their name to things they do not mean.

The deposit or pre-pay. A landing page, a real price, and a checkout that takes a refundable deposit or a discounted annual pre-pay. If people will put down $50 against a thing that does not exist, you have found something rare. If they will not, better to learn it now for the cost of a Stripe account than after a launch.

I’ll be straight: I have not pre-sold a SaaS. I built first. That is exactly the mistake this section argues against, and I’m writing it partly to hold my own future self to it. The founders worth copying did the opposite. Nathan Barry built ConvertKit by personally onboarding early customers and asking for the sale before the product was anything like finished. Pieter Levels has charged for half-built products for years and let paying users decide what to build next. The pattern is identical: take money or a hard commitment first, build to honor it second.

One honest caution: pre-selling works cleanly for B2B and for clear, painful, expensive problems. It works less well for low-price consumer products where the buyer decides in ten seconds and will not pre-commit. For those, a working demo and a paid acquisition test replace the pre-sell. Match the test to the buyer.

What a real validation week looks like

Validation should be timeboxed and cheap, or it becomes its own form of procrastination. Here is a one-week version a solo founder can actually run.

• Day 1: Write the one-sentence problem and the buyer. Build a list of 30 people who plausibly have both.
• Day 2 to 3: Send 30 personalized outreach messages asking for a 20-minute conversation about their workflow. No pitch.
• Day 4 to 5: Run the conversations that land. Take notes on past behavior, current spend, and who holds budget.
• Day 6: Stand up a one-page site with the promise and a real price. Add a deposit or a “reserve a spot” commitment.
• Day 7: Send the page to everyone who described the pain specifically. Count commitments.

At the end of the week you do not have a product. You have something better: evidence. You know whether the pain is specific, whether a buyer exists, and whether anyone will move money or reputation before you build.

The cost of this week is your time and maybe $20 for a domain and a landing page. Compare that to three months of nights and weekends spent coding a product nobody asked to pay for.

Here is the real cost of the week I just described, on the stack I actually use. A domain runs about $10 a year. The landing page sits on Cloudflare Pages for free. Stripe in test mode is free until you take a real payment. Call it under $15 to find out whether anyone will pay, against three months of evenings you would otherwise spend building blind. I have never regretted spending that $15. I have regretted skipping it.

The SaaS Validation Scorecard

Conversations and pre-sells generate signals. You still have to decide. Founders are bad at deciding because they grade their own homework with a bias toward “build.” A scorecard externalizes the judgment.

Score each row 0, 1, or 2. Total out of 14.

Dimension	0 points	1 point	2 points
Pain specificity	Vague annoyance	A described recent incident	A quantified cost in time or money
Current spend	Nobody pays for anything	A workaround they tolerate	Real budget already spent on a substitute
Buyer access	You can’t reach buyers cheaply	One slow channel	A repeatable channel you control
Commitment evidence	Likes and “sounds great”	A booked call or waitlist	A deposit, LOI, or design-partner yes
Frequency	Rare, once a year	Occasional	Weekly or daily pain
Your unfair edge	None	Some domain familiarity	Distribution, expertise, or speed others lack
Reachable price	Buyer won’t pay your floor	Maybe at a discount	Price clears your break-even with margin

Reading the score:

• 11 to 14: Build the smallest version. The evidence is strong.
• 7 to 10: Run one more pre-sell test before committing engineering time.
• 0 to 6: Walk, or change the buyer. The idea may be fine; the market you picked is not.

The scorecard’s value is not the number. It is that it forces you to write down weak rows you were ignoring. The row most founders score 0 and pretend is a 2 is “commitment evidence.” Be honest about that one and you will save yourself a quarter.

What I would do differently, and where validation misleads

I want to argue against my own advice, because the strongest version of this should survive the obvious objection.

Some great products skipped formal validation. The founders had such deep domain knowledge that they were the market, and conversations would have produced worse answers than their own conviction. Superhuman, the email client, was famously built on the founder’s own taste before broad demand testing. Validation theater can also produce false negatives: genuinely new categories are hard to pre-sell because buyers cannot imagine the outcome you are describing. Ask people in 2006 to pre-pay for “an app store on your phone” and most say no.

So the rule is not “always pre-sell or always build.” The rule is to know which regime you are in. If you have rare, earned conviction about a buyer you understand better than they understand themselves, weight your judgment higher. If you are a technical founder who likes the idea of a market you have never sold into, weight the evidence higher and trust yourself less.

This is also why I run several small products instead of one big bet. Not as a hedge against boredom, but so that no single idea has to be right for the operation to survive. Each one has to earn its place by clearing the same bar: cheap to test, honest about commitment, fast to kill if the buyer never shows up. The founders who compound are not the ones who fall in love with an idea. They are the ones who keep asking the market to pay before they spend.

The mistake I made, and see most often, is treating validation as a gate to pass rather than a habit to keep. You do not validate once. You validate the idea, then the price, then the onboarding, then every major feature. The founders who compound are the ones who keep asking the market to pay before they spend, long after the first yes.

Want the system, not just the article?

This post is one play. The Bootstrapped Founder Operating System packages validation, pricing, and the first-100-customers playbook into a fillable workbook with the SaaS Validation Scorecard, the five-conversation script, and a pre-sell page template you can ship the same day. Launch price: $29. Get the workbook →