How to Validate a SaaS Idea Before Building
A practical framework for testing customer demand, reducing uncertainty, and avoiding months of building around an unproven assumption.
A SaaS idea can sound convincing in your head and still fail in the market. The risk is not that you cannot build the product. It is that you build something people do not care enough about to adopt or pay for. Validation replaces assumptions with evidence before you commit months of engineering time.
Start with a Problem, Not a Feature
Write the problem in one sentence. Avoid describing the product you want to make. Describe a situation a specific person repeatedly experiences.
“Small retailers need better software” is too broad. “A store owner spends several hours each week reconciling orders from multiple sales channels in spreadsheets” is testable. It identifies a person, a recurring task, and a potential cost.
The Riskiest Assumptions Matrix
Rank assumptions by uncertainty and impact. An assumption that nobody wants to change their workflow will invalidate the product regardless of your code quality.
| Assumption | Evidence to seek | Low-cost test |
|---|---|---|
| Problem happens weekly | Concrete examples from past 14 days | Discovery interview |
| Existing tools are inadequate | Specific manual workarounds and scripts | Workflow observation |
| A buyer will pay money | Upfront deposit, LOI, or pre-order | Paid pilot offer |
| The audience is reachable | Predictable outbound response rates | Targeted LinkedIn / email outreach |
Common Mistakes to Avoid
- Asking leading questions: Never ask “Would you buy this?” Ask “When did you last spend money trying to solve this?”
- Confusing traffic with demand: Page views indicate curiosity; credit card deposits indicate commercial intent.
- Building before speaking to 10 buyers: Engineering is the most expensive way to discover nobody wants your product.
Continue to Module 2: Customer Discovery Interviews to learn the 20-minute discovery script.