Grentech
All insightsStrategy

How to validate a SaaS idea before writing code

Grentech insights · 7 min read

Most SaaS ideas fail for a reason that has nothing to do with engineering: nobody validated whether the problem was worth solving, for whom, and at what price, before building it. The good news is that validation doesn't require code, a designer, or months of runway — it requires discipline and a willingness to hear 'no'.

Start with the problem, not the product

It's tempting to describe your idea in terms of features. Resist that. Describe the problem instead: who has it, how often, and what they currently do about it. If you can't describe the current workaround in detail — the spreadsheet, the manual process, the workaround tool — you probably don't understand the problem well enough yet to solve it.

Talk to fifteen people before you talk to a developer

Fifteen structured conversations with people who genuinely have the problem will tell you more than any amount of internal debate. Ask about their current process, what it costs them (time, money, stress), and what they've already tried. Avoid asking whether they'd 'use' your idea — hypothetical enthusiasm is cheap. Ask what they're doing about the problem today.

Test willingness to pay before you test the interface

  • A landing page describing the outcome, not the features, with a clear call to action
  • A concierge version of the service, delivered manually, to prove the value before automating it
  • A short paid pilot with a handful of early customers, even if delivery is partly manual

Each of these approaches produces a stronger signal than a finished product with no users. If people won't pay for a manual version of your idea, a polished app is unlikely to change their mind.

Scope the smallest version that proves the value

Once you have signal, resist the urge to build everything at once. Identify the single workflow that delivers the core value, and build only that — deliberately excluding the features that feel important but aren't yet proven. This is the point at which a structured discovery sprint earns its cost: it turns validated demand into a scoped, buildable first version.

Validation isn't a phase you complete once. It continues through the first release and beyond — but doing the groundwork before writing code dramatically improves the odds that what you build is worth using.