TL;DR: Most SaaS products fail not because of bad code — but because nobody wanted what was built. This guide shows how to test real demand, willingness to pay, and viability before writing a single line of code. Methods that take days, not months.
You have a SaaS idea. Maybe you’ve already opened your code editor. Before you commit anything, read this.
The scenario is common: a technical solo builder spends 2-4 months building a product. Backend done, frontend working, deployed. Launches. Discovers nobody wants to pay for it.
It wasn’t a lack of technical skill. It was a lack of validation.
The most expensive mistake a solo builder makes isn’t writing bad code. It’s writing good code for something nobody wants.
This article is a survival manual to avoid that trap.
The core mistake: coding before validating demand
As a technical builder, you have a dangerous advantage: you can build anything. And that’s exactly what screws you.
The sequence most people follow:
- Have an idea
- Choose the stack
- Design the database
- Build the backend
- Do the frontend
- Deploy
- Launch
- Discover nobody wants it
The correct sequence:
- Have an idea
- Test if someone would pay for it
- Discover what exactly that person wants
- Build the minimum necessary
- Deliver to those who already showed interest
- Iterate with real data
The difference between the two sequences is time — and money. The first burns months. The second spends days.
Why do technical builders fall into this trap?
Three reasons:
- Building is comfortable. Validating is uncomfortable. You need to talk to people, hear “no,” deal with rejection. Code never rejects you.
- Building feels like progress. You see commits, lines, features. It feels like you’re advancing. But advancing in the wrong direction is just organized waste.
- You confuse “I’d use it” with “I’d pay for it.” If you’re the first user, you’re not the market. You tolerate bugs, understand the product, have context. Your customer doesn’t.
What “validating” really means
Validation is NOT:
- posting on Twitter and counting likes
- asking friends if the idea is good
- creating a survey and getting polite answers
- showing the product and receiving compliments
Validation is answering one objective question:
“Are real people willing to pay real money for this — right now?”
Anything that doesn’t involve financial commitment or concrete action is just opinion. And opinion doesn’t pay for servers.
The 4 levels of validation (and why most people stop at the wrong one)
Not every signal of interest is worth the same. There’s a clear hierarchy:
Level 1: Curiosity
The person says: “Interesting…” or “Cool…”
This is worth nothing. Curiosity doesn’t turn into purchases. A curious person doesn’t open their wallet.
Level 2: Interest
The person says: “I’d use that” or “I need that.”
Better, but still weak. Verbal interest doesn’t translate into payment. People are polite. They say what you want to hear.
Level 3: Intent
The person does something concrete: signs up for the waitlist, fills out a form, schedules a demo, asks for early access.
Now there’s a signal. But it’s still low-cost. Clicking a button doesn’t commit anything.
Level 4: Payment
The person pays. Even if it’s a $2 deposit, a $5 pre-sale, or any real amount.
That’s validation. Money changing hands is the only signal that truly matters.
The rule is clear: if you haven’t reached level 4, you don’t have enough validation to build.
Types of validation that actually matter
There are ways to test demand that generate reliable signals. All of them involve real commitment from the potential customer.
Pre-sale
Offer the product before building it. With a real price. With a deadline.
Example message:
“I’m building a tool that [solves X for Y]. It’ll cost $29/mo. I’m offering pre-sale at $14/mo for the first 10 users. Want to secure your spot?”
If someone pays, you have validation. If nobody pays, you saved months.
Waitlist with strong action
Don’t just collect emails. Ask for something that filters out the curious:
- form with 3-5 questions about the problem (intentional friction)
- a “why do you need this?” field (mandatory text input)
- a symbolic payment link to “guarantee priority”
Someone who fills out a detailed form is more committed than someone who just drops an email.
Conversations with clear pain
People describing the problem in detail, citing tools they’ve already tried, explaining how much time they waste. That’s evidence of real pain — especially if the person has already spent money trying to solve it.
People trying to solve the problem today
If you find someone using a spreadsheet, a poorly configured Zapier setup, or a manual process to solve something your SaaS would handle — that person is a potential customer. They’ve already proven the problem exists by investing time in it.
Money changing hands
The gold standard. Even if it’s a symbolic payment, a refundable deposit, or an aggressive pre-sale discount. If the person opens their wallet, the problem is real.
Practical validation methods without code
You don’t need a product to test if someone wants your product. These methods work in days.
1. Landing page with clear proposition
Create a simple page with:
- Problem: describe the pain you intend to solve
- Solution: explain how your SaaS solves it (no technical details)
- Price: yes, include a price. Price filters the curious
- CTA: “Reserve access for $X” or “Secure pre-sale spot”
Free tools: Carrd, Framer, Notion published as a page.
What to measure: CTA clicks. If 100 visits generate zero clicks, the proposition doesn’t resonate.
Tip: use exactly the language you’ve seen potential customers use. Not your jargon. Their words.
2. Payment button before the product
Set up a checkout on Stripe, PagSeguro, or similar. The button leads to a thank-you page that says: “You’ll be notified when the product is ready.”
If nobody clicks, nobody wants.
If someone clicks and pays, congratulations — you have a customer before you have a product.
3. Form with intentional friction
Instead of an email field, create a form that requires effort:
- “Describe how you deal with [problem] today”
- “How much time do you spend on this per week?”
- “How much would you pay to solve this?”
- “Leave your email for early access”
Who fills everything out is committed. Who drops out at the first field was never a customer.
4. Targeted cold outreach
Find 20-30 people who likely have the problem. Send a direct, honest message:
“Hi [name], I saw you [relevant context]. I’m researching [specific problem] and wanted to ask: how do you deal with this today? Takes 2 minutes.”
Don’t sell. Ask. If the person responds in detail and shows pain, dig deeper. If they ask to see the product — you have a lead.
Where to find them: LinkedIn, niche communities, Twitter, Reddit, Discord/Slack groups.
5. Posts in specific communities
Publish in communities where your audience is. Don’t post “check out my product.” Post about the problem:
“Anyone here waste time on [specific problem]? How do you deal with it today?”
If the post generates dozens of responses describing frustrating workarounds, you’ve found demand.
Ideal communities: niche subreddits, professional Discords, Slack groups, industry-specific forums.
6. Fake demos (concierge / Wizard of Oz)
Offer the service as if it were a product, but execute it manually behind the scenes.
Example: instead of building a report automation SaaS, you generate the reports manually using scripts and send them by email. The customer thinks it’s a product. In reality, it’s you.
This tests if someone wants the result without you building anything. If the customer pays for the manual service, they’ll pay for the automated product.
How to structure a validatable value proposition
Before testing anything, you need to clearly articulate what you’re offering. A validatable value proposition has four elements:
1. Specific problem
Not “helping companies be more productive.” That means nothing.
Better: “Freelancers lose 5 hours a week organizing contracts, invoices, and deadlines in different spreadsheets.”
2. Specific audience
Not “companies” or “people.”
Better: “Tech freelancers generating between $1k and $6k/month who work with 3-10 simultaneous clients.”
3. Measurable result
Not “being more efficient.”
Better: “Reduce from 5 hours to 30 minutes the time spent on client management per week.”
4. Clear promise
Not “a better tool.”
Better: “A dashboard that consolidates contracts, invoices, and deadlines for all your clients in one place — no spreadsheets.”
If you can’t write all four elements in 2 sentences, the idea isn’t clear enough to validate.
How to talk to potential customers without useless interviews
Badly conducted interviews generate false data. The most common mistake is asking about the future:
- “Would you use a product that does X?” → everyone says yes
- “How much would you pay for this?” → hypothetical answers are inflated
- “Do you think this is a good idea?” → people are polite
Instead, focus on the past and present:
Ask about current behavior:
“How do you solve [problem] today? Show me.”
If the person opens a spreadsheet with 3 tabs and 4 manual integrations, you have evidence of real pain.
Ask about previous attempts:
“Have you tried solving this another way? What did you try? Why didn’t it work?”
If the person lists tools they tried and explains why they didn’t work, they know the problem deeply.
Ask about current cost:
“How much time or money do you spend dealing with this per week?”
Time is money. If someone spends 5 hours/week on something your SaaS would solve in 30 minutes, the value is measurable.
What to observe (not ask):
- Does the person talk a lot about the problem? → real pain
- Does the person mention spending they’ve already made trying to solve it? → willingness to pay confirmed
- Does the person ask “when will it be ready?” → genuine interest
- Does the person respond with one word (“yes,” “maybe,” “interesting”)? → weak signal
How to detect false positives
Not every positive signal is validation. There are false positives that deceive unprepared builders.
The polite one:
The person says the idea is great, they’d definitely use it, it should exist. But when you offer early access or ask them to pay, they disappear.
Warning sign: praise without commitment.
The curious one:
The person signs up for the waitlist, follows the updates, but never converts to payment. They like the idea, but don’t need it.
Warning sign: engagement without financial action.
The technical peer:
Another dev says “great job, congrats!” and shares it with their network. But they’re not your customer. They’re your colleague. Peer validation isn’t market validation.
Warning sign: validation comes from someone who wouldn’t pay.
The AI enthusiast:
Someone says “this with AI would be incredible!” but doesn’t describe a real problem they have. They’re excited about the technology, not the solution.
Warning sign: excitement about tech, not about the problem.
How to filter:
- Always offer the chance to pay, even symbolically
- Request actions with friction (detailed form, deposit, commitment)
- Check if the validator is actually the buyer
- Be suspicious of any signal that doesn’t involve cost for the person
How to define a “validation threshold” before writing code
Before starting any test, define the criteria that will tell you whether to build or not. Without this, you’ll rationalize any positive result.
Example threshold for a $29/mo SaaS:
- Minimum 10 CTA clicks on the landing page out of 200 visits
- Minimum 5 people filling out the form in detail
- Minimum 3 conversations with clear pain described
- Minimum 2 real payments (pre-sale or deposit)
If you don’t hit those numbers, don’t build.
The rule: define the threshold BEFORE testing. After the test, it’s too easy to move the goalposts.
Concrete validation examples
Validating an automation SaaS
Scenario: You want to build a tool that automates Google Analytics reports for agencies.
Test in 5 days:
- Day 1: Create a landing page on Carrd describing the problem (“Agencies waste hours creating manual reports for clients”) and the solution (“Automatic GA4 reports, emailed, with your branding”). Price: $39/mo.
- Day 2-3: Post in 3 agency communities (Reddit r/digital_marketing, Facebook groups, agency Slack). Don’t sell. Ask: “How much time do you spend building GA4 reports for clients?”
- Day 3-4: Send 20 direct messages to agency owners on LinkedIn. Offer early access.
- Day 5: Measure. If 3+ people showed clear pain and 1+ paid a deposit, build.
Validating a paid API
Scenario: You want to offer an API that generates article summaries using AI.
Test in 3 days:
- Day 1: Create a landing page with simulated API docs. Show request/response examples. Include per-call pricing ($0.01/request).
- Day 2: Post in dev communities (Hacker News, Reddit r/webdev, developer Discords). Describe the problem the API solves.
- Day 3: Measure. If devs asked about rate limits, SDKs, and detailed pricing, there’s real interest. If they asked to test it, build a working endpoint.
Validating an internal tool turned product
Scenario: You have a script you use yourself to monitor competitor prices. You want to turn it into a SaaS.
Test in 7 days:
- Day 1-2: Describe what the script does in business language, not technical. “Monitor competitor prices and get alerts when they change.”
- Day 3: Offer the service manually. “I’ll monitor 5 competitors for you and send weekly reports for $49/mo.”
- Day 4-7: If 2+ people accepted and paid, you have validation to automate.
Validating an AI product
Scenario: You want to build a tool that generates product descriptions for e-commerce using AI.
Test in 5 days:
- Day 1: Create a landing page with examples of generated descriptions. Show before/after.
- Day 2: Offer manual generation via form. “Submit 5 products and I’ll generate optimized descriptions. $29.”
- Day 3-4: Post in e-commerce communities (r/ecommerce, store owner groups, dropshipping forums).
- Day 5: Measure. If people paid for the manual service, they’ll pay for the automated product.
How to turn validation into first customers
Validation isn’t the end — it’s the beginning. When you have real signals, use them to build the right version of the product.
Use the validators’ words
The phrases your potential customers used describing the problem become your copy. Their language is more persuasive than anything you’d write.
If someone said: “I use 3 different tools and still miss deadlines” — that phrase becomes your landing page headline.
Deliver to those who already showed interest
Don’t launch to the world. Deliver first to those who paid, signed up, or talked to you. These people are your first customers and your best feedback.
Offer:
- early access
- lifetime discount
- direct communication channel (Slack, WhatsApp, Discord)
Define scope by what was validated
If in validation people asked for “automatic reports” and nobody mentioned “interactive dashboard,” build reports. Ignore the dashboard. The market told you what it wants.
Your MVP should be the smallest possible version that delivers what was validated. Nothing beyond that.
When to stop validating and start building
Signs it’s time to write code:
- 2+ real payments (pre-sale, deposit, or early purchase)
- 5+ conversations with detailed pain described (people citing tools, processes, time wasted)
- Clear pattern among validators (same problem, same language, same willingness to pay)
- You know exactly what the first feature is (the market told you, you didn’t invent it)
If these conditions exist, stop validating and build. Don’t waste more time testing. Build the minimum and deliver.
When to kill the idea without attachment
Signs it’s time to abandon:
- Zero payments after 100+ landing page visits
- Nobody described the problem in detail in conversations
- People say “interesting” but don’t take action (no forms filled, no deposits)
- You need to convince people the problem exists (if you need to convince, it doesn’t exist)
- The validators aren’t the buying audience (other devs, friends, family)
Killing an idea isn’t failure. It’s efficiency. Every idea killed early is a product you didn’t build for nobody.
Clinging to an idea without validation is the most costly mistake a solo builder can make.
Common validation mistakes (and how to avoid them)
Asking for opinion instead of commitment
“What do you think?” generates opinion. “Will you pay?” generates validation.
Whenever possible, put a price on the conversation. Even a symbolic one.
Validating with the wrong audience
Validating with other technical builders isn’t validating with customers. Your dev cousin isn’t your market. People in your tech Discord aren’t your customers.
Validate with people who have the problem, not with people who understand technology.
Not charging early
“I’ll launch for free and charge later.” Mistake. The time to charge is now. If nobody pays $10, nobody will pay $100.
Charging filters the signal. Removes false positives. Shows real demand.
Building an MVP too large
Your MVP doesn’t need:
- authentication from 3 providers
- a dashboard with 12 charts
- integration with 5 APIs
- pixel-perfect design
Your MVP needs:
- solve the validated problem
- accept payment
- work
Confusing engagement with demand
A post about your idea with 200 likes isn’t validation. It’s engagement. People can like an idea without ever paying for it.
Validation = payment. Engagement = vanity metric.
FAQ
How much time should I spend validating?
Between 3 and 14 days. Less than 3 days, the data is insufficient. More than 14 days, you’re procrastinating or avoiding building.
Can I validate with ads?
You can, but ads validate interest in clicking, not in paying. Use ads to drive traffic to a landing page with a payment CTA. The ad click isn’t validation — the purchase button click is.
What if I can’t talk to anyone?
Your audience might not be on the channels you searched. Try other channels. If nowhere wants to talk about the problem, maybe the problem doesn’t exist for anyone else — and that’s valuable information too.
Do I need a prototype to validate?
No. For most SaaS, a clear landing page with a value proposition and payment button is sufficient. A prototype is for when you already have validation and want to test usability.
What if validation is partial?
Some people showed interest, but not enough to hit your threshold. In that case, adjust: change the angle, redo the value proposition, test with a different audience. Don’t build yet, but don’t give up immediately.
How do I validate if my SaaS is B2B?
Cold outreach is the most effective method for B2B. Send direct messages to decision makers. Ask for 15 minutes of conversation. If nobody wants to talk, the problem isn’t a priority for that audience.
Conclusion
Validating a SaaS isn’t an academic process. It’s a practical test of a simple hypothesis: will someone pay for this?
The steps are straightforward:
- Articulate the problem and audience clearly
- Define your validation threshold before testing
- Test with fast methods (landing page, outreach, communities)
- Request real commitment — money, time, action with friction
- If you hit the threshold, build the minimum and deliver
- If you don’t, kill the idea and move to the next one
The time you spend validating isn’t wasted time. It’s the cheapest investment you make. One week of validation saves months of useless construction.
Don’t start with code. Start with the question that matters: “Will someone pay for this?”
If the answer is yes — and you have data to prove it — then open your code editor.
