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. Once you are running it for real, the solo founder operating system is how you keep the whole thing straight. And if you are not sure what to build, turning a service you already sell into SaaS is one of the safest paths.

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.

What are the false signals that feel like validation?

Four signals feel like progress and prove nothing: survey enthusiasm, your own conviction, audience applause, and the existence of competitors. Each one is free for the other person to give, which is exactly what makes it worthless as evidence. These four 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 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.

What questions should you never ask a potential customer?

Never ask a question that invites a prediction or a compliment. “Would you use this?”, “Does this sound useful?” and “How much would you pay?” all ask someone to forecast the behavior of a more disciplined future version of themselves. Replace every one of them with a question about something that already happened.

Question that fools you	Why it fails	Ask this instead
”Would you use this?”	Predicts a future self who is more organized than the real one	”What did you do the last time this came up?"
"Do you think this is a good idea?”	Requests an opinion about you, not a fact about the problem	”How are you handling it today?"
"How much would you pay?”	Stated prices run high because saying a number costs nothing	”What are you paying for the workaround now?"
"Would you pay $49 a month?”	Anchors them and turns discovery into a negotiation	”Who signs off on a $49-a-month tool in your team?"
"What features do you need?”	Promotes a buyer into an unpaid product manager	”What broke last time, and what did it cost you?"
"Is this a problem for you?”	A yes-or-no question invites politeness	”How many times did this happen last month?”

Two rules keep a discovery call honest. The first is the talk ratio: if you spoke for more than about a third of the call, you ran a pitch and collected no data. The second is the date test. Every useful answer has a date attached to it, because a fact happened at a time and an opinion did not. “We deal with this constantly” is an opinion. “It cost us Tuesday and Wednesday last month” is a fact.

Close every call with two asks that cost the person almost nothing and are worth a lot to you. Ask who else has the same problem, which is how a list of thirty becomes a list of sixty. Then ask permission to come back when you have something to show, which converts a stranger into a warm contact for the pre-sell step without asking for a commitment they are not ready to make.

How do you pre-sell software that doesn’t exist yet?

You pre-sell with three things: a credible promise, a real price, and a way to take a commitment. No product required. Conversations prove the pain is real. A pre-sell proves the pain is worth money to this buyer at your number, which is the harder fact and 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.

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.

How do you validate a SaaS idea with no audience?

You replace inbound interest with a named list. Thirty specific people, one personalized message each, one small ask: twenty minutes about how they handle the problem today. No audience means no shortcut. It does not mean no path. The list is the asset, and you can build one in an afternoon.

Named buyers are easier to find than founders assume, because people with expensive problems talk about them in public. Six sources that produce names rather than traffic:

• People who left detailed reviews on a competing or adjacent tool, especially the two-star and three-star ones. They have already spent money on this problem and told you exactly what disappointed them.
• Forum, Reddit, and Slack posts describing the problem in the last ninety days. Recency matters more than volume.
• Speaker and attendee lists from small industry conferences and meetups, which are usually public.
• Issue threads and discussions on open-source projects in the same workflow, where the complaint is often precise and technical.
• Guests on niche podcasts in the space, who have publicly declared their role and their opinions.
• Anyone in your own contacts who holds the job title of your buyer, plus one introduction requested from each of them.

Plan the arithmetic before you start, because it is the part founders get wrong. Assume a low reply rate on genuinely personalized cold outreach and a fraction of those replies converting to a booked call. On that planning assumption, one batch of thirty messages yields a couple of conversations, not five. Budget two batches across two to three weeks to reach the five you need. Treat those figures as a planning model rather than a measured benchmark, and recalculate with your own reply data after the first batch.

Four things lift reply rate more than message length: a specific reason you picked that person, no attachment and no link in the first message, exactly one question, and an explicit escape hatch such as “if you are not the right person, no reply needed.” The honest constraint is that a cold message from a domain with no reputation gets filtered before a human sees it, so warm introductions outperform cold outreach by a wide margin at this stage. Spend your first hour asking each existing contact for one introduction, then go cold for the rest.

There is a deeper point underneath the tactics. Paul Graham’s argument in How to Get Startup Ideas is that the best ideas come from problems the founder already lives with, and part of why that works is access. Sit inside the problem and you already know thirty people who have it. If you do not, buying that access with outreach is a real cost to price in before you commit a quarter.

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 are the most common SaaS validation mistakes?

Five mistakes account for most wasted validation effort: pitching inside the discovery call, interviewing users instead of budget holders, accepting compliments as evidence, choosing a problem whose buyer you cannot reach, and letting validation run forever because no answer was ever allowed to be a no.

Pitching inside the call. The moment you describe the product, the person switches role from witness to supporter and every answer after that is contaminated. The fix is procedural, not a matter of willpower: do not open the deck, do not name the product, and keep the five past-tense questions in front of you.

Interviewing users instead of buyers. In B2B these are frequently different people with opposite incentives. The user wants the tool and has no budget. The manager holds the budget and feels the pain only as a line item. Validating with users alone produces enthusiastic calls and no purchase orders. Always ask who signs off, then get to that person.

Accepting compliments as evidence. “This is exactly what we need” is a sentence people say to be kind. Write it in your notes as encouragement, not data. Only a scheduled call, a signed letter of intent, or money moves a row on the scorecard.

Picking a problem with an unreachable buyer. This one is quiet and expensive. The pain can be real, frequent, and worth money, and the idea still fails because your only route to the buyer is a channel you cannot afford. Score buyer access honestly before you write code, because a great product aimed at people you cannot reach is a distribution problem wearing a product costume.

Never letting the answer be no. Founders who cannot fail a test will run one more interview, then one more, until the calendar decides for them. Set the kill criteria before you start: the date, the number of commitments required, and what you will do if you do not get them. A test with no failure condition is not a test.

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 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.

One newer hazard is worth naming, because it did not exist when most validation advice was written. An AI model asked whether your idea is good will find reasons it works, in fluent and specific-sounding detail, which feels like analysis and functions as agreement. AI product research without fooling yourself covers how to rewrite the question so the answer is worth something.

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 →