Validating a SaaS Idea Before Hiring Any Developer

The most expensive mistake I see founders make is hiring a developer to build a product that hasn't been validated. The build goes well. The product ships on time. The product is technically excellent. Nobody buys it. The founder spent $25,000 to learn that customers didn't actually want what they thought they wanted, when $300 of validation work would have surfaced the same answer in a week.

Real validation is unpopular because it's harder than building. It requires uncomfortable conversations with potential customers, asks for money before there's a product, and accepts the possibility that the answer is "no." Building feels productive. Validation feels like bureaucracy. The pull toward building is strong.

This article is about the validation work that actually predicts whether your SaaS will work, separated from the validation theatre that lets you feel good without learning anything.

What validation theatre looks like

Things that feel like validation but aren't:

Survey responses. "Would you use a product that does X?" 62% said yes. This means almost nothing. Survey respondents say yes to things they would never actually pay for, because saying yes is free and saying no feels rude. Forrester research consistently shows that 60–80% of survey respondents who claim they'd buy a hypothetical product don't actually buy it when offered.

Informal interest. Friends, family, and Twitter followers all enthusiastically saying they'd use it. None of them are customers. They're being nice. Their opinions don't predict whether real buyers will pay.

Email signups. "We got 1,000 people on the waitlist!" Email signups cost the signer nothing. The conversion from waitlist to paying customer is typically 1–5%. If your waitlist is 1,000 people, expect 10–50 paying customers — not 1,000.

Conference applause. Pitching the idea to an audience and getting positive feedback. Audiences clap for everything. Their applause doesn't translate to wallets.

Investor enthusiasm. Multiple investors saying "this is interesting." Investors say "interesting" to everything that's not actively bad. It doesn't mean they'd invest. It doesn't mean customers exist. It's polite engagement, not validation.

The pattern: real validation requires the validator to give something up — money, a public commitment, time on their calendar. If they're not giving anything up, their interest doesn't predict their behaviour.

What real validation looks like

Three forms of validation that actually predict revenue:

Form 1: Pre-orders with deposits

The strongest signal you can get pre-build: a real customer paying a real deposit for a product that doesn't exist yet.

The technique: a landing page with the value proposition, a specific price, and a "reserve your spot" button that takes a partial payment ($50–$500) via Stripe. The deposit is fully refundable if you don't ship within X months.

What this gives you:

Real cash from real customers, not survey enthusiasm.
A customer list with verified payment methods and email addresses.
A clear signal of which features in your value prop actually mattered to buyers.
A built-in launch audience.

What this requires: the courage to ask for money before the product exists. This is the part most founders skip. They feel weird asking for money "before there's anything to give them." That weirdness is information — if you're not comfortable asking for money for what you're describing, the buyer probably isn't comfortable paying for it either. Fix the value prop until you're comfortable asking.

A real benchmark: if you can get 5 paying deposits from cold outreach to your target market, the product has signal. If you can get 20+, the product has strong signal. Below 5, you don't have validation; you have a hypothesis.

Form 2: Letters of Intent (B2B specifically)

For B2B SaaS where the buyer needs internal approval before paying, an LOI is the equivalent of a pre-order deposit. A signed LOI saying "we will pay $X/month for this product if you ship by Y date" is real commitment, not enthusiasm.

LOIs work because they're a mini-contract. The signer is putting their name on a document that they'd be embarrassed to renege on. They've usually had to talk to their boss or finance team to get authority to sign. The mental commitment is significant.

What an LOI should include:

The buyer's name, title, and company.
The price they'll pay (per month or per year).
The features that are non-negotiable to them.
A target date by which they need it shipped.
A signature.

You don't need a lawyer to draft this. A simple Google Doc works fine. The LOI isn't legally binding (and shouldn't be) — it's a behavioural signal. If a buyer won't sign an LOI for the product they say they want, they probably won't pay for it when it's built.

A real benchmark: 3 LOIs from real target buyers is enough to start building. 8+ is strong validation. Below 3 means you don't actually have a product — you have an idea your friends like.

Form 3: Calendar commitment from real buyers

For products where pre-orders or LOIs are awkward (consumer tools, very early-stage), the alternative validation is real time-on-calendar from real target customers.

The technique: 20 deep customer conversations with actual target buyers. Not your friends. Not random Twitter followers. Real people who match your target customer profile.

What "deep" means: 30–60 minutes per conversation. Recorded with permission. Open-ended questions about the problem, not the solution. You learn what they actually do, what they currently use, what frustrates them, what they wish existed.

What you're looking for:

Consistent themes across multiple conversations (not just one or two).
Specific descriptions of pain ("I do X every Friday and it takes 4 hours") rather than vague complaints ("nothing on the market is great").
Mentions of money — what they currently spend on related solutions, what they'd be willing to spend on a better one.
Direct questions like "if I built this, would you buy it for $X/month?" answered with "yes" and a follow-up commitment to be the first user.

A real benchmark: after 20 conversations, you should be able to describe your target customer's pain in their words, name 3+ specific people who'd buy V1, and have a price point that matches what they currently spend on related solutions.

If you can't, you don't have validation. You have research that needs to continue.

The 5-paying-customer threshold

Below all of this is a single threshold: don't hire a developer until you have 5 customers willing to pay for V1.

"Pay" can mean any of:

5 deposit-paid pre-orders
5 signed LOIs from B2B buyers
5 verbal commitments from people you've spoken to in depth, with their phone number / email and a verbal "yes, I'll be the first to pay $X/month when it's ready"

The number 5 isn't magic. It's the threshold where you've moved from "interesting idea" to "people are willing to put something on the line." Below 5, building is gambling. Above 5, building is execution.

The threshold is an intentionally low bar. If you can't clear 5 from cold outreach to your target market, the product isn't ready to build. You either have a validation problem (the thing isn't actually wanted) or a positioning problem (the thing is wanted but you're describing it badly). Both need to be solved before code is written.

What to do if you can't get to 5

Common reasons founders can't clear the threshold:

Reason 1: the target market isn't reachable

You're trying to build for "small business owners" but you have no way to talk to small business owners. The product might be valid; the validation can't proceed because you can't reach the buyers.

The fix: pick a narrower target you can reach. If you can reach 50 e-commerce store owners through a community you're part of, validate against that subset first. The narrower target is enough to prove demand. You can broaden later.

Reason 2: the value prop is too vague

You're describing a product that does five things, and prospects can't grasp what they'd get. Their interest is polite but not specific.

The fix: cut the value prop to one thing. The clearer the offer, the easier validation becomes. "I help busy founders save 10 hours a week on calendar management" is validatable. "I help founders work better" is not.

Reason 3: the price is wrong

You're asking for $500/month from buyers whose problem is worth $50/month to them. Or you're asking for $30/month from buyers whose problem is worth $1,000/month — which sounds underpriced but actually triggers "this is too cheap to be real" rejection.

The fix: ask validators directly. "If this existed and worked, what would feel reasonable to pay?" The number they say is your starting price. Match the price to the perceived value, not to your cost or aspiration.

Reason 4: the timing is wrong

The market exists, but it's not buying right now. You picked a category in the middle of a trough. Validation conversations are friendly but nobody's buying anything in that category right now.

The fix: validate harder. Push for "would you buy now?" not "would you buy someday?" If timing is the problem, real conversations will surface it. You either pivot to a related category that is buying, or wait for the cycle to turn.

Reason 5: there isn't actually a market

The hardest possibility to accept: the product genuinely isn't wanted. Your hypothesis is wrong. The market doesn't exist or is too small to support a business.

The signal: 30+ conversations with target buyers, no clear pattern of demand, no specific buyer who's willing to commit. At this point, the responsible move is to stop and pick a different idea, not to build the wrong one anyway.

This is the cheapest possible negative result. You spent 4 weeks of validation work and learned the idea was wrong. Compare to spending 4 months and $25k of build work to learn the same thing.

How long validation should take

A realistic timeline:

Week 1: list 50 target customers. Reach out to them.
Weeks 2–4: have 15–20 deep conversations. Record the patterns.
Weeks 4–6: build the landing page and start asking for deposits / LOIs.
Weeks 6–8: hit the 5-customer threshold or learn that you can't.

Six to eight weeks of validation work, before any code is written. This sounds like a lot. It's much less than the time you'd spend rebuilding a product that turns out to be wrong.

What to do next

Once you've cleared the validation threshold, the next decisions are scope (the right MVP definition for your situation) and team (who builds it). See:

If you've validated and you're ready to start building, the first call is free — see Full-Stack for Bootstrappers or SaaS Startups.

---

Part of the Full-Stack Development for Solo Founders pillar guide.