Most SaaS ideas fail before anyone builds them. The build happens anyway because nobody stopped to check. This 4-step validation process gives you the answer before you write the first line of code. Four prompts. Under 60 minutes. Every output tells you something concrete.
You have a SaaS idea. First instinct: open the editor. Start thinking about the tech stack, the database, authentication. That is the default. And most of the time, it is backwards.
Not because the idea is bad. Because you skipped the step that tells you whether anyone will pay for it.
Run this validation first. Build after.
What This Validation Actually Covers
Four questions, in order. Each one gets an AI-powered answer you can verify.
- Who would actually pay for this?
- What already exists in the market?
- Where is the real gap?
- What should you build first?
Most SaaS failures skip questions one through three and go straight to building, which is question four without the context. The result is a product that technically works and commercially doesn't.
This process takes 60 minutes. It has saved six weeks of building the wrong thing more than once.
What Is the Real Cost of Skipping This?
The average first SaaS product built without validation loses three to six months on a scope no buyer asked for. Then it gets rebuilt, pivoted, or abandoned.
The validation doesn't guarantee success. It removes one specific failure mode: building something technically correct that nobody pays for. That mode is common, and avoidable.
Step One: Build the Buyer Profile
Before anything else, you need one specific person who will pay for this. Not a demographic. Not a category. A person.
Run this in Claude or Codex. Be specific about the idea before you paste it in.
Copy this.
I have a SaaS idea: [DESCRIBE YOUR IDEA IN 2-3 SENTENCES].
Give me a buyer profile. Include:
- Job title and company size of the person most likely to pay for this
- The specific problem they have right now that this solves
- How they currently handle this problem (workaround, manual process, or competitor tool)
- What they have already tried that did not fully work
- What they would describe as the cost of the problem in concrete terms:
time per week, money lost, or risk created
- What would make them switch to a new tool today
Make the profile specific. Name the friction, not the category.
Do not describe an ideal customer. Describe the person most likely to pay first.
The output tells you whether you are building for a real person or a category. Categories do not buy software. People do.
Your First Real Run: Take the output and ask yourself: can you name three actual companies where this exact person works right now? If you can't, the profile is still too broad. Run the prompt again and add: "Narrow this to one specific industry vertical."
The Mistake That Makes It Fail: Treating the AI output as validated truth. The model will give you a plausible answer. Your job is to find two or three people matching that profile and ask them whether it's accurate. One real 20-minute conversation is worth more than ten AI outputs. The prompt prepares you for that conversation.
Done. You have a buyer.
Step Two: Map What Already Exists
You know who you are building for. Next: what have they already been offered?
Copy this.
I am building a SaaS product for this buyer:
[PASTE THE BUYER PROFILE FROM STEP ONE]
List every product, tool, and workaround that currently tries to solve this problem.
For each option, give me:
- Product name and approximate monthly price
- What it does well for this buyer
- Where it consistently fails or frustrates this buyer
- Who its primary users are: small business, mid-market, enterprise, or freelancer
- Whether it appears to be growing, stable, or declining
After listing the options, give me the gaps: specific things this buyer needs
that none of these options currently deliver.
Look for two things in the output.
First: there is competition. That means the problem is real and people pay to solve it. Zero competition almost always means zero market. Not zero competition because you are early, zero competition because the problem is not painful enough to buy a solution for.
Second: there are specific gaps that none of the existing tools close. The gap is where you build.
Your First Real Run: Look up two or three of the tools the model names. Verify they exist. Check their actual pricing page. If the model invented a product, the gap analysis in step three will also be wrong. Verification takes five minutes and saves you from building toward a phantom gap.
The Mistake That Makes It Fail: Trusting the gap the model identifies without checking the complaints. Search G2, Product Hunt, and Reddit for the tools it named. Find the one-star reviews. The real gap lives in the complaints, not in the feature comparisons. What people complain about and what marketing materials say are different things.
Done. You have a competitive map and a list of gaps.
Step Three: Define the Real Gap
You have a buyer profile and a competitive map. The gap is where the buyer's specific pain meets the market's specific blind spot.
Copy this.
Based on the buyer profile and competitive landscape above: Define the gap this SaaS should occupy. Be specific. Tell me: - What does the buyer need that no current tool delivers? - Why have existing tools not solved this? Is it a technical limitation, a pricing model mismatch, an audience mismatch, or something else? - What would success look like for the buyer in concrete terms: time saved per week, revenue recovered, or specific risk removed? - What is the minimum feature set that delivers that outcome without requiring a full-featured product to work? Do not suggest a feature list. Describe the outcome the buyer needs and explain why nothing currently delivers it.
The gap definition is the most important output of this entire process.
If you cannot state the gap in one sentence after reading the output, you do not have a clear enough thesis to build from. Run the prompt again and add: "Give me the gap in one sentence of under 20 words."
Your First Real Run: Write the gap in one sentence without looking at the model's output. Then compare it to what the model said. Where they diverge, investigate. Your sentence represents what you believed before validation. The model's sentence represents what the evidence suggests. The divergence tells you where your assumptions were off.
The Mistake That Makes It Fail: Widening the gap to include multiple problems. One specific gap. One specific buyer. That is a product. A solution to multiple vague problems is a consulting engagement. Keep cutting until you have one sentence.
Done. You have the gap.
Step Four: Sequence What to Build First
You know the buyer, the market, and the gap. Now: what is the smallest thing that proves the concept?
Copy this.
Given this gap: [PASTE YOUR ONE-SENTENCE GAP DEFINITION] And this buyer: [PASTE THE BUYER PROFILE FROM STEP ONE] What is the minimum viable version of this product that a buyer would pay for today? Tell me: - The one workflow it needs to handle end-to-end - What input the user provides and what output they receive - What integrations are required for the first version, if any - What a paying customer would reasonably pay per month for this version alone - What one feature would make them upgrade to a more complete product Do not describe a product roadmap. Describe only the thing you build first. The thing someone pays for today.
The output tells you what version one is. Not the vision. The first paying version.
Your First Real Run: Estimate how long version one would take to build alone. If it is more than six weeks of solo work, the scope is too large. Run the prompt again and add: "Narrow the first version to two weeks of solo development. What stays and what moves to version two?"
The Mistake That Makes It Fail: Building version two first. Every feature that goes beyond the minimum described here delays your first paying user. Delay your first paying user and you delay the feedback that tells you whether you are building the right thing.
Done. You have a build target.
The Comparison That Changes How You Work
| Without Validation | With Validation |
|---|---|
| Idea → Editor → 6 weeks building | 60 minutes → Buyer profile → Competitive map → Gap → Build target |
| Feature scope determined by your assumptions | Feature scope determined by what a specific buyer pays for |
| Pivot after launch when adoption fails | Narrow before launch based on what the market says |
| Zero confidence in pricing | Pricing informed by what comparable tools charge |
| First user: yourself | First user: someone matching the buyer profile |
The 60 minutes does not guarantee the idea works. It removes the most common failure mode.
What This Process Does Not Cover
Validation tells you whether a market exists and what the minimum version should be. It does not tell you:
- Whether you can execute the build in the time estimated
- Whether your pricing will hold once buyers see the product
- Whether the gap you identified will remain a gap for the next 18 months
These are real questions. They do not get answered by the validation process. They get answered by building and watching.
Run the four prompts, then book three 20-minute calls with people who match the buyer profile. Do not pitch the product. Ask them to describe the problem in their own words. If they use different language than the model used, trust their words. They are the ones paying.
The validate-breakdown PDF below gives you the full framework in printable format.
If You Only Do One Thing This Week
Take the SaaS idea sitting in your notes. Run prompt one: the buyer profile. Get the output. Then name three companies where that buyer works right now.
If you can name them, you have a buyer worth building for. If you can't, the idea needs another hour of thinking before it needs any code.
The six weeks you save are the six weeks you spend building the right thing.