How to Validate a SaaS Idea Before You Write Code

Most failed SaaS products don't fail because of bad engineering. They fail because the team spent months building something nobody needed badly enough to pay for. Validation is the cheapest insurance you can buy against that outcome, and it doesn't require a working product. Start with the problem, not the feature list. Write down, in one sentence, who has the problem and what it currently costs them — in hours, dollars, or missed opportunities. If you can't state the cost concretely, you probably don't understand the problem well enough to build for it yet. Talk to the people who have the problem before you talk to anyone about your solution. Fifteen structured conversations with real prospective users will tell you more than a landing page full of assumptions. Ask about how they solve the problem today, what they've already tried, and what they'd have to see to switch. Resistance to switching is often the biggest hidden cost in a SaaS business — a mediocre existing workflow that "sort of works" is a stronger competitor than any other startup. Look for evidence of willingness to pay, not just willingness to complain. A spreadsheet workaround, a Zapier chain held together with duct tape, or a line item in someone's budget for a worse competing tool are all stronger signals than "yeah, I'd probably use that." If you can, ask for a small deposit, a signed letter of intent, or early access to a waitlist with a credit card on file. Money, even a small amount, filters out politeness from real intent. Build the smallest possible thing that tests your riskiest assumption — not the smallest version of your final product. Those are different exercises. If your biggest risk is "will anyone integrate this into their existing workflow," a working prototype of the integration matters more than a polished dashboard. If your biggest risk is "will people pay a recurring fee for this," a manually-delivered version of the service, billed monthly, tells you more than an automated MVP ever could. Set a validation budget in time, not features. Give yourself a fixed number of weeks to get a clear yes or no from the market, and be honest with yourself about what counts as a "yes." A handful of enthusiastic conversations that never convert to a paying pilot is a maybe, not a yes — and maybes are how teams end up building for a year on a foundation that was never actually there.