How to Validate a SaaS Idea Before You Write a Line of Code

Most failed SaaS products did not fail because the code was bad. They failed because nobody wanted to pay for the thing the founders built. Validation is the work you do before you write a line of code to make sure you are not about to spend six months on a beautifully engineered product that solves a problem too small, too rare, or too cheap to support a business.

The good news is that a SaaS idea can be validated in three to five weeks for under three hundred dollars. The bad news is that most founders skip this because building feels like progress and talking to strangers feels like delay. The order matters — every week of validation saves roughly a month of wasted building later.

Start with a sentence, not a feature list

Before anything else, write one sentence in this shape: 'I help [specific role] at [specific kind of company] do [specific task] so they can [specific outcome].' Bad version: 'I help small businesses save time on operations.' Good version: 'I help operations managers at three-to-twenty-person agencies reconcile time tracking with client invoices so they can bill weekly instead of monthly.'

If you cannot write that sentence, you are not ready to validate — you have an idea about a category, not an idea about a customer. The narrower the sentence, the easier every later step becomes: you will know exactly who to interview, exactly which forums to read, and exactly which ad audience to target.

Do ten to fifteen problem interviews

Find ten to fifteen people who match that sentence and ask them about the problem, not your solution. The goal is to learn how they describe the pain, what they already pay for, and what they have tried. Three questions do most of the work: 'Walk me through the last time you did this task. What did you use? What was annoying?' Listen for spending. If the person already pays for spreadsheets, contractors, or a clunky tool, the problem is real. If they shrug, it is not.

Booking those interviews is itself a validation signal. If you cannot get fifteen meetings out of a hundred targeted LinkedIn messages or cold emails, your customer is hard to reach — and a SaaS business is largely a customer-acquisition business. That is a finding worth more than the interviews themselves.

Build a landing page, not a product

Describe the product on a single page as if it already exists. Show the outcome, name a price, and put a button that says 'Get Early Access' or 'Start Free Trial.' Use a tool you already know — Carrd, Framer, Webflow, or a simple Next.js page. The page should take a day, not a week.

Spend one hundred to two hundred dollars on tightly targeted ads — LinkedIn for B2B roles, Reddit or niche newsletters for prosumer audiences, Google Search for high-intent keywords like 'reconcile time tracking with invoices.' Send the traffic to your page and measure two things: the click-through to the call-to-action and the percentage of visitors who hand over an email.

• Below one percent email capture on tightly targeted traffic: the message or the audience is wrong.
• Two to five percent: a real signal — keep iterating on copy and audience.
• Above five percent on a hundred-plus visitors: strong signal, move to a paid pilot.
• Always include a price or price range — vague pricing inflates signups and destroys signal.

Run a concierge or Wizard-of-Oz pilot

Take the first five or ten people who signed up and offer them the outcome at a real price — fifty to two hundred dollars a month is fine — but deliver it manually behind the scenes. Use spreadsheets, Zapier, and your own hands to produce the result. The customer never sees the seams; you learn exactly what the product needs to do, and you collect real revenue.

If five strangers will not pay even a small amount for a manually delivered version of the outcome, no amount of polished software will change that. If they do pay, you now have paying customers, a recorded workflow, and a far better product spec than any document you could have written in advance.

Numbers that mean 'go,' 'maybe,' and 'no'

Validation is judged on patterns, not single data points. After three to five weeks of work, look at the combined picture: how easy it was to book interviews, how clearly people described the pain in their own words, how strongly the landing page converted, and how many people paid for the manual pilot. Match the evidence to one of three outcomes and act accordingly — refusing to decide is itself a decision to keep burning time.

• Go: interviews were easy, three or more people pre-paid or signed letters of intent, and conversion was strong.
• Maybe: interest exists but no money moved — narrow the customer, raise the price, or sharpen the outcome and re-test.
• No: hard to find the customer, vague pain, no payment despite multiple asks. Stop and pick a sharper problem.

When you are finally ready to build

You are ready to write code when the only remaining question is whether you can build the product well — not whether anyone wants it. By that point you should know the exact job to be done, the price the customer accepts, the channel that brings them in, and the workflow you intend to automate. Build the smallest version that delivers the promised outcome for the first ten paying customers, and keep delivering the rest manually until the product catches up.

Validation does not eliminate risk; it transfers risk from 'will anyone care?' — the question that kills most SaaS companies — to 'can we execute?' — the question founders are usually better equipped to answer. That trade is the whole point of doing the work before you ship a single line of code.