How to Validate a SaaS Idea Before Writing Code

Why Most Founders Skip Validation

Building feels like progress. Writing code, designing screens, setting up infrastructure — these are tangible activities that feel like work. Validation feels like stalling.

The result is a common pattern: founders spend 3-6 months building a product, launch it, and discover that the audience they imagined doesn’t exist, or doesn’t want to pay, or already uses something that solves the problem well enough.

Validation isn’t stalling. It’s compressing the feedback loop. The question isn’t “should I validate?” — it’s whether you want to find out in 30 days at landing page cost, or in 6 months at engineering cost.

Step 1: Define Your Buyer Precisely

Vague ICPs produce vague validation data. “Small businesses” tells you nothing. “Owner-operators of residential HVAC shops with 1-5 trucks who currently use Jobber and hate per-user pricing” is specific enough to write targeted copy, target specific communities, and evaluate whether your signups are actually your buyer.

Write this sentence before you write any copy:

“[Role] at [company type] who [specific problem]. They currently use [existing solution] and their main frustration is [specific frustration].”

If you can’t write that sentence clearly, your idea isn’t specific enough to validate yet. Narrow it further.

Step 2: Build the Minimal Validation Page

Your page needs three things:

1. Problem statement — describe the frustration your buyer lives with, not the feature you’re building. If they recognize themselves in the first sentence, they’ll read on.
2. Who it’s for — explicitly name the buyer. “Built for HVAC shops running 1-5 trucks” tells the right buyer they’re in the right place and tells the wrong buyer to leave. Both are good outcomes.
3. Email capture with a specific promise — “Get early access” is weak. “Get notified when we launch + a 30-day free trial for early signups” is concrete.

No feature lists. No “our mission” copy. No founder story. Those come after you’ve confirmed someone cares.

Step 3: Add Fake-Door Pricing

Add a pricing section with real tiers and real prices. Wire each “Get Started” button to record which tier was clicked, then redirect to your waitlist or a “You’re on the list” page.

You now know:

• Which tier attracted the most interest
• Whether anyone clicked at all (if not, pricing is too high or the copy before it wasn’t convincing)
• Whether more people clicked Starter vs. Pro (price sensitivity signal)

This is the Buffer model. Gascoigne launched a landing page with pricing before writing any backend code. Clicking a pricing tier redirected to a “not ready yet” page — but the click itself told him someone wanted what he was describing at that price. That’s the whole test. You don’t have to go that far. Tracking which tier gets clicked is enough signal without taking payment.

import InlineSignup from ‘@validation/ui/components/inline-signup.astro’;

Step 4: Generate Search Traffic with pSEO

A landing page with no traffic gives you no data. You need visitors who have the problem you’re solving.

pSEO is a traffic strategy that attracts buyers with demonstrated intent. When someone searches “best alternative to [competitor you’re displacing]” or “how to [problem you solve],” they’re actively researching. That’s better signal than someone who clicked a social post because the headline was interesting.

For a validation site, 10-20 pages is enough to start seeing traffic:

• Alternatives pages: “[Competitor] alternative” — captures buyers who are evaluating options
• Comparison pages: “[Tool A] vs [Tool B]” — captures buyers deep in evaluation
• Guide pages: “How to [problem you solve]” — captures buyers researching the problem
• Pricing pages: “[Competitor] pricing” — captures price-sensitive buyers who want to understand costs

Each page is a landing page in its own right. Readers find the content, read it, and encounter your email capture CTA at the bottom. A well-targeted pSEO page converts at 2-5% from organic traffic.

Step 5: Run the Experiment and Decide

Set your kill criteria before you start. You will rationalize mediocre results if you don’t have pre-defined thresholds.

Kill the idea if:

• Under 2% email conversion after 100 visitors
• Post-signup survey responses show no consistent pain point
• 30+ days pass with no inbound discovery call requests

Continue if:

• 5-10% email conversion
• Survey responses cluster around a specific, consistent pain point
• At least one buyer asks when they can use it or book a call

Strong signal (start building):

• Above 10% email conversion
• Multiple buyers proactively ask for a demo or offer to pay now
• Fake-door pricing clicks concentrate on one tier

Track these numbers weekly. Don’t adjust your kill criteria mid-experiment.

What Happens After Validation

If the experiment fails: you found out in 30 days and spent less than $100. Take what you learned about buyer objections and reframe or pivot the idea. Run another 30-day experiment.

If the experiment passes: you have email signups, fake-door pricing data, and survey responses. You know your buyer, their biggest pain, their price sensitivity, and what they’re currently using. Build the minimum feature set that addresses the pain — no more.

The validation data shapes your roadmap. You’re not guessing anymore.

import DefinitionBlock from ‘@validation/ui/seo/definition-block.astro’; import AnswerBlock from ‘@validation/ui/seo/answer-block.astro’;