How To Validate a SaaS Idea Before Development

Step 1: Define the Problem, Not the Solution

Most founders start with a solution ("I want to build an app that does X") instead of a problem ("Y type of person struggles to do Z"). The problem definition is more important than the solution, because the same problem can have many valid solutions, and your first instinct on the solution is usually not the best one.

• Write: "Who specifically has this problem? (job title, company size, industry)"
• Write: "What are they currently doing to solve it? (spreadsheet, manual process, existing tool)"
• Write: "Why is the current solution inadequate? (too slow, too expensive, too unreliable)"
• If you cannot answer all three specifically, you have not defined the problem yet

Step 2: Interview 20 Potential Users

User interviews are the cheapest and most reliable validation tool available. Twenty conversations, done correctly, will tell you more than any survey or analytics tool.

1. 1Find potential users through LinkedIn, communities (Slack groups, Reddit), or your existing network.
2. 2Ask about the problem, not your solution: "How do you currently handle X?"
3. 3Ask about frequency and severity: "How often does this happen? What does it cost you?"
4. 4Ask about existing solutions: "Have you tried any tools to fix this? Why did they not work?"
5. 5Do not pitch your product during these calls — listen and document.

Step 3: Test Willingness to Pay

Interest is not demand. The only way to validate demand is to test whether someone will exchange money (or a significant commitment of time) for your product.

• Pre-sell access: "We're launching in 6 weeks. You can lock in the founding member price today."
• Collect deposits ($100–$500) — a deposit filters genuine interest from polite curiosity
• Collect LOIs (Letters of Intent): common in B2B, constitutes a written commitment to purchase
• If 10 people say they'd pay but zero provide a deposit, the price or the urgency is wrong

Step 4: Build a Landing Page, Not a Product

A landing page with a clear value proposition and a waitlist signup collects real demand signals before a line of product code is written. Measure:

• Conversion rate on the waitlist signup (target: >5% of unique visitors)
• Email open rate on follow-up (target: >40% — indicates genuine interest)
• Qualitative feedback from signups (run a 3-question form after signup)
• Cost per acquisition via paid ads (this reveals your customer acquisition cost before you have a product)

Step 5: Manually Deliver the Core Value Before Automating It

The "Concierge MVP" or "Wizard of Oz" technique: deliver the value of your product manually for your first 5–10 customers before building the automated version. This validates that the value is real and that customers will pay for the outcome, regardless of how it is delivered.

• Example: if you are building a data pipeline tool, manually run the pipeline for first customers in a spreadsheet
• This reveals what users actually value vs what you assumed they valued
• It produces your first revenue before your first line of product code
• It gives you real requirements from real usage, not assumed requirements from interviews

Implementation Checklist

• Problem defined: who, what current solution, why inadequate
• 20 user interviews completed, key pain points documented
• At least 3 pre-payments or LOIs collected
• Landing page live with >5% conversion rate on waitlist
• Concierge delivery for 3–5 customers completed
• Core value proposition confirmed: users pay for the outcome, not the features

Common Mistakes to Avoid

• ✗Asking "would you use this?" instead of "will you pay for this?" — the former gives you optimism, the latter gives you data
• ✗Validating with friends and family — they are biased toward encouragement, not honest feedback
• ✗Building the landing page to look like the product — validate the problem, not the UI
• ✗Waiting for "perfect" validation before starting development — 3 paying customers is sufficient signal
• ✗Ignoring signals that the market is too small — if fewer than 10,000 businesses have the problem, unit economics may not work

Frequently Asked Questions