Founder guide · Phase 1 of the F.O.U.N.D.E.R. Method

How to Validate a SaaS Idea Before You Build

By Shayan Junaid, founder of The Operators Club

Validation isn't about proving an idea sounds good. It's about finding out whether there's a real, recurring, commercially valuable problem — strong enough to justify building a SaaS product around it.

This is the exact process we use with founders before a single line of code is written. By the end, you should know who has the problem, how often they face it, how they solve it today, what they already spend, why current solutions fall short, and who could become your first beta users.

1. Start with the founder, not the product

Every founder starts from a different place. A beginner has an idea but doesn't know if it's worth building. An agency owner notices clients keep asking for the same thing. A service business does something manually that could become software. An existing SaaS founder has users but stalled growth.

So first, look at what you already have access to:

• Existing business, customers, and services
• Existing audience and distribution
• Industry knowledge
• Operational problems and recurring requests

The best SaaS opportunity is often hiding inside something you already understand.

2. Identify the problem

Don't hunt for random ideas. Look for problems that repeatedly create friction, cost, lost time, manual work, lost revenue, or inefficiency — customers asking for the same service, staff repeating the same manual task, a process spread across disconnected tools, or customers paying different providers for the same outcome.

Remember: a problem is not automatically a SaaS opportunity. It needs investigating.

3. Run the multiple-user test

Is this happening to multiple people or businesses? One client asking for a very specific automation is a custom requirement. Ten clients asking for variations of the same automation is worth investigating. The question becomes: can this repeated problem be standardized?

4. Understand the current solution

Don't jump to "Would you use my SaaS?" — it's too early. Ask: how are you solving this today? People are already doing something: another SaaS, a stack of tools, spreadsheets, WhatsApp, freelancers, an agency, internal software, a manual workaround — or ignoring it.

5. Find the existing spend

Money already attached to a problem is one of the strongest validation signals. Find out who they pay, how much, how often, how much time it costs, and what happens if it goes unsolved.

"Yeah, this would be useful" is weak. "I'm currently paying $500 every month to solve this" is completely different — there's already money in the market.

6. Learn why the current solution isn't enough

Competition doesn't mean no opportunity. Ask what's wrong with what they use now: too expensive, too slow, too complicated, missing features, too much manual work, doesn't fit their workflow, doesn't integrate — or they don't know a solution exists. This is where your competitive advantage appears. The goal isn't something completely new; it's understanding what would make someone switch or pay for something better.

7. Talk directly to the people who have the problem

Reach them through existing customers, your network, LinkedIn, communities, cold outreach, industry groups, introductions, or your audience. The goal isn't to pitch. It's to learn.

8. Run structured discovery calls

Move qualified people onto a call and get answers to these questions:

1. Tell me how you're currently handling this.
2. How often does this problem happen?
3. What do you currently use to solve it?
4. What do you dislike about your current solution?
5. How much does this currently cost you?
6. How much time does it take?
7. What happens if you don't solve it?
8. Have you already tried fixing it?
9. If a solution solved this properly, would you consider using it?
10. What would it need to do to be actually valuable?

Notice how little of the call is about your product. Understand their world first.

9. Don't ask for compliments

"Do you like this idea?" gets a yes from almost everyone — and means nothing about paying. Look for behaviour instead: "I'm already paying for this." "I spend 5 hours every week on this." "We use three different tools." "If you build this, I'd want to test it."

Behaviour is stronger than compliments.

10. Identify potential beta users

Discovery calls double as your beta pipeline. Anyone with the problem, urgency, existing spend, interest in a better solution, and decision-making authority is worth keeping close. Ask: "If we build a solution around this, would you be open to testing the early version with us?"

11. Score the opportunity

12. Apply the biggest filter

Not "Is this cool?", "Can we build it?", "Can AI make it?" or "Does a competitor have it?" The only question that matters before an MVP:

Is there enough evidence of commercial demand to justify building?

Real example: Sassy Digitizing

The founder already ran a design and digitizing business with B2B customers. The SaaS idea: give customers easy access to high-quality designs in one place, instead of repeatedly buying designs across different platforms.

Rather than building because the idea sounded good, we started from the existing business: existing B2B customers, existing design requirements, existing spend, and a recurring need for new designs. The question to validate became whether those customers would want a recurring model — and they could become the first beta users.

Instead of Idea → Development → Launch → Hope people come, the path becomes Existing Problem → Existing Customers → Validation → Beta Users → MVP.

What you should have at the end: a Validation Brief

• Problem — what exactly are we solving?
• ICP — who exactly experiences it?
• Current solution — how is it solved today?
• Existing spend — what do they pay now?
• Pain — why isn't the current solution enough?
• Desired outcome — what do they actually want?
• Demand evidence — what did conversations reveal?
• Potential beta users — who agreed to test?
• Recurring revenue potential — why pay again next month?
• MVP direction — the core outcome the MVP must deliver.

When to move on to building

Not when you're excited — when the evidence is strong. You're ready when you can say: I know my customer, their problem, how they solve it today, and why that isn't enough; I've spoken to people who have it; I've found potential beta users; and I understand what they'd pay for. That's where Phase 2 — MVP Definition & Build Strategy — begins.

Validate whether a real customer has a recurring problem, already spends resources solving it, wants a better solution, and can become an early user.