How I'd Validate a SaaS Idea in 2025 (Without Writing Code)

I’ve built 5 products nobody wanted. Spent months coding features for phantom users. Burned through savings chasing ideas that were dead on arrival.

If I had to validate a new SaaS idea today, before touching any code, this is exactly how I’d do it.

No landing pages. No wait lists. Just the validation tactics I wish I’d known before wasting 2 years of my life.

1. Stop validating the problem. Validate the payment.

Everyone tells you to “validate the problem first.” They’re half right.

Yes, problems need to exist. But here’s what I learned the hard way: people complain about tons of problems they’ll never pay to solve.

“My CRM is too complicated” doesn’t mean they’ll switch. “I hate doing invoices” doesn’t mean they’ll buy your tool. “This process is manual” doesn’t mean they want it automated.

The only validation that matters is this: Will someone give you money to solve this problem?

Not “would you use this?” Not “is this a pain point?” But “here’s my credit card.”

If I were starting today, I’d skip the problem validation surveys entirely. Instead, I’d go straight to testing if anyone would pay — even before building anything.

2. The “Fake Door” Test (That Actually Works)

Here’s what most people get wrong about fake door tests: they make them too fake.

A landing page with an email capture? That’s not validation. That’s a vanity metric. I had 2,000 emails for a product that got 3 paying customers.

Here’s what actually works:

1. Create a simple page that describes your solution (not the problem)
2. Add real pricing
3. Put a “Start Free Trial” or “Get Started” button
4. When they click, show: “We’re at capacity but can manually onboard 5 customers this week. Book a call?”

Then get on calls and be honest: “We’re in early access. I’ll personally help you implement this solution. It’ll be manual at first, but you’ll get white-glove service.”

If they bail when they realize it’s not automated yet? They were never going to pay anyway. If they’re still interested? You’ve got validation.

I validated my last product this way. 3 out of 10 calls converted to paying customers — before I wrote a single line of code.

3. Manual First, Automate Never (Until You Have To)

This one hurts to write because I’m a developer. I love building things.

But the fastest way to validate is to become the product yourself.

Want to build an invoice automation tool? Offer to do invoices manually for 5 customers. Building a social media scheduler? Schedule posts manually using spreadsheets. Creating a feedback aggregator? Copy-paste feedback into a Google Doc.

Yes, it’s unsexy. Yes, it doesn’t scale. That’s the point.

You’ll learn:

• What the actual workflow looks like
• Which features matter and which don’t
• What edge cases will break your beautiful automation
• Whether people will actually pay when the problem is “solved”

One founder I know validated a $50K/year SaaS by being a human API for 3 months. Brutal? Yes. But he knew exactly what to build when he finally wrote code.

4. The “Concierge MVP” Nobody Talks About

Everyone knows about concierge MVPs in theory. Almost nobody does them right in practice.

Here’s the framework that actually works:

Week 1-2: Find 10 potential customers (not friends, real prospects)
Week 3: Offer to solve their problem manually for 50% off your planned price
Week 4: Deliver the service, track every minute detail
Week 5: Ask for feedback and payment
Week 6: Decide if it’s worth building

The key is the 50% discount. It’s enough to incentivize early adoption but high enough to validate real willingness to pay.

If you can’t find 10 people to talk to, the market’s too small. If you can’t get 3 to try it at 50% off, the problem’s not painful enough. If they try it but won’t pay, your solution doesn’t work.

No code. No landing pages. Just pure validation.

5. The “Competitor’s Customers” Goldmine

Want to know the fastest way to validate demand? Find people already paying for a solution.

But here’s the twist: don’t ask them what they hate about their current tool. Everyone hates something about every tool they use.

Instead, ask:

• “What made you choose [Competitor] over the others?”
• “What would have to be true for you to switch?”
• “What’s the one thing they could remove that would make you cancel?”

Then shut up and listen.

If 5+ customers mention the same switching criteria, and you can deliver it, you’ve got validation. If everyone loves their current solution except for the price, you’ve got validation. If they all mention a missing feature their vendor refuses to build, you’ve got validation.

I spent 3 days in Reddit threads and Facebook groups where my competitor’s customers hung out. Found 15 people willing to switch for one specific feature. That’s all the validation I needed.

6. Price Before Product

This is the most counterintuitive advice I’ll give you: Set your pricing before you know what you’re building.

Why? Because pricing determines everything:

• Who your customers are
• What features matter
• How much support you can offer
• Whether the unit economics even work

If you’re thinking $10/month, you need thousands of customers. Different game. If you’re thinking $500/month, you need dozens. Completely different validation.

Here’s my pricing validation framework:

1. Find 10 competitor prices
2. Talk to 5 current buyers in the space
3. Ask: “What would X need to cost for it to be a no-brainer?”
4. Set your price at 70% of that number
5. Validate if you can deliver value at that price

If you can’t make the economics work, kill the idea now. Not after you’ve built it.

7. The “10 Customer Rule”

Here’s my personal rule: If I can’t imagine getting 10 paying customers, I don’t build it.

Not 10 interested people. Not 10 email signups. 10 people with credit cards ready.

And here’s the kicker: I need to be able to name them. Not “small businesses” or “freelancers” — but actual names or specific companies.

This forces you to get specific. “Project managers at 50-person SaaS companies who use Jira but hate it” is validatable. “People who need productivity tools” is not.

If you can name 10 potential customers and how you’d reach them, you’ve got something. If you’re making up personas and hoping they exist, you don’t.

8. Stop Asking “Would You?” Start Asking “Did You?”

Hypothetical questions get hypothetical answers.

❌ “Would you pay for a tool that does X?”
✅ “When did you last pay for a tool to solve X?”

❌ “How much would you pay for this?”
✅ “How much do you currently spend on this problem?”

❌ “Would this feature be valuable?”
✅ “Tell me about the last time you needed this.”

Past behavior predicts future behavior. Everything else is just polite fiction.

When I validated UserJot, I didn’t ask if people would want a feedback tool. I asked: “Show me your current feedback system.” The mess they showed me was all the validation I needed.

9. The “Refund Test” Nobody Does

Here’s a validation technique that’ll save you months: Offer to sell your non-existent product with a money-back guarantee.

“Pay $49 today. If we can’t deliver [specific outcome] in 30 days, full refund.”

Then deliver it manually. If you can’t, refund them.

This does three things:

1. Forces you to make concrete promises (not vague benefits)
2. Validates price sensitivity with real money
3. Teaches you if your solution actually works

The beauty? If everyone asks for refunds, you’ve learned the idea doesn’t work for the cost of some manual labor. That’s insanely cheap validation.

If 70%+ keep paying? You’ve got a business.

10. When to Give Up (The Part Nobody Talks About)

Here’s the truth: Most ideas should die in validation.

Give up if:

• You can’t get 10 people on the phone to discuss the problem
• Less than 30% of people you pitch to are interested in paying
• Your manual version has >50% refund requests
• You can’t profitably deliver value at any price point
• The unit economics don’t work even at scale

Don’t pivot. Don’t iterate. Just move on.

I killed 3 ideas last year in validation. Saved me probably 18 months of wasted effort. That’s not failure — that’s intelligence.

The Validation Stack That Actually Works

If I were validating a new SaaS idea tomorrow, here’s my exact 30-day plan:

Days 1-5: Research competitors, find where their customers complain
Days 6-10: Have 20 conversations with potential customers
Days 11-15: Create “fake door” test with real pricing
Days 16-20: Get 10 people into paid manual trials
Days 21-25: Deliver service manually, track everything
Days 26-30: Collect payment or kill the idea

No code. No landing pages. No wait lists.

Just real validation with real customers paying real money.

Because here’s what I wish someone had told me 5 years ago:

The goal isn’t to validate that a problem exists. The goal is to validate that you can profitably solve it.

Everything else is just expensive procrastination.

---

P.S. One thing I learned too late: you’ll forget 90% of what people tell you during validation. Every objection, every “almost” is your real product roadmap. Set up UserJot from day one to capture it all. Future you will thank you.