Why most SaaS ideas fizzle out.

I’ve been there.

Over the years, I’ve started more side projects than I can count. Most of them never made it to sharing, let alone an actual launch. Some got stuck in “just one more feature”. Others were polished endlessly with no clear audience in mind.

To be fair, many of those projects were just technical explorations; a chance to try a new tool, framework, or idea. They didn’t need to be released. But when I set out to build something real, something others might use or pay for, that same pattern kept showing up: overbuilding and undervalidating.

Even today, I still fight my instinct to just build.

If you’ve had a similar experience, know this: you’re not alone. But there’s a more focused way to approach early-stage, B2B SaaS. It starts with identifying a problem that is… PURRDD?

PURRDD? Find a good B2B problem.

Whenever I have an idea, I try to test it against this list of requirements should-really-haves:

• Painful
• Urgent
• Recurring
• Recognised
• Defined well
• Difficult to delegate

These are not hard requirements, but you’ll make your life a lot easier by ticking off as many as you can. Our B2B monday.com calendar startup ticks off 4-5 of these. On the other hand, it’s a lot harder to justify our B2C tourism startup based off this list.

Let’s dive into each requirement.

Painful: What’s really costing them?

A good SaaS idea solves a painful problem. It’s a good thing then that pain can take many forms!

• Time cost: Is this problem consuming hours every week?
• Money cost: Is it causing revenue loss or inefficient spend?
• Reputation risk: Could failing to solve it damage trust or credibility?
• Cognitive overload: Is it mentally exhausting or unnecessarily complex?
• Skill gap: Does it require skills the user doesn’t have?
• Compliance or legal risk: Are they worried about breaking rules?
• Security risk: Is there potential for data loss or breach?
• Integration/collaboration: Are the tools they use not talking to each other?
• Scaling limits: Is growth being held back by this problem?
• Customer impact: Does it create frustration or churn?

Find people (it can be you yourself) who are struggling with this problem and interview them to explore the problem. It’s easiest when you’re surrounded by these people. If not, you’ll need to make use of your network or online communities.

Urgent: Why the problem can’t wait.

Urgency separates a “nice-to-have” from a “must-solve.” If the problem isn't addressed in the next few weeks or months, what’s the consequence?

• Are customers leaving?
• Is the team wasting hours doing something manually?
• Are they delaying growth or revenue?
• Is a compliance risk or legal deadline approaching?

Picture a small business that tracks client renewals in a spreadsheet. (Don’t underestimate how many businesses run on spreadsheets.) Everything works, until one day, it doesn’t. A key renewal slips through the cracks, the client loses access to their product, and decides to take their business elsewhere. A single oversight turns into an painful, and costly mistake. That’s what urgency looks like.

Recurring: Does the pain keep coming back?

If someone only experiences the problem once, it’s unlike they’ll pay to solve it, or even realise they could have benefitted from your solution. You want problems that show up consistently:

• Every day, week, or month
• During repeatable workflows
• At regular business milestones (e.g. onboarding, bookings, renewals, reporting, reviews)

Recurring pain justifies recurring revenue. If the problem keeps coming back, your solution becomes a core part of their workflow.

Recognised: Do they even acknowledge they have the problem?

You can’t sell a solution to a problem people don’t know they have or won’t acknowledge. If they don’t recognise the pain, they won’t be looking for a solution, and they certainly won’t be searching for your product.

A recognised problem is one they can clearly describe in their own words. You’ll hear it in their complaints, see it in their online questions, or spot it in the tools they duct-tape together.

If you ask “What’s the hardest part of your job?” and they mention it unprompted, that’s gold. If they’ve already hacked together a solution with spreadsheets, Zapier, or interns, even better.

Don’t try to educate people into feeling pain. Find those who already feel it. They’ll be far more motivated to engage, give feedback, and pay.

Defined well: Avoid ambiguity

Ambiguous problems are dangerous. You’ll build features that serve no one well. You want to be able to clearly define:

• Who has the problem
• When it happens
• What they’re trying to do at that moment
• Why their workaround fails

Narrow each point as best you can. Instead of saying “people struggle with onboarding,” say “freelance accountants in New Zealand spend hours explaining recurring billing to new clients via email, which leads to delays and scope creep.”

That level of specificity makes the solution obvious, and the product easier to market.

Difficult to delegate: Is the pain stuck with them?

The best SaaS problems are ones that the person experiencing them can’t easily hand off. If they could pay someone else to deal with it, they probably already would.

Look for problems that sit at the intersection of responsibility and context, where solving it requires specific domain knowledge, decision-making authority, or personal involvement.

• A founder tracking customer renewals and missing key accounts
• A finance lead reconciling revenue from multiple channels
• A consultant manually preparing repetitive client reports

These roles can’t simply outsource the pain because it ties directly to accountability or trust. If your solution gives them leverage, not just automation, you’re onto something valuable.

Shrink the problem

Make your audience smaller. Serving “startups” or “freelancers” is too broad. Pick a niche: “NZ-based mortgage brokers onboarding self-employed clients,” for example.

A tight focus makes your message clearer and helps early adopters feel like the product was made for them… because it was! It also keeps your scope manageable.

Build the simplest thing

Now comes the part where most people overbuild. You don’t need:

• Single Sign-On
• Integrations
• Team management
• Onboarding flows
• Analytics dashboards

All of that can come later. Start with the simplest possible version that proves your solution works. This could be:

• A small prototype that addresses the pain
• A short demo video showing how you solve their pain
• Or even a marketing website with a waitlist

Your job isn’t to impress, it’s to validate. If you solve the right problem, even the ugliest prototype will resonate.

Conclusion

If your idea isn’t gaining traction, don’t write more code. Zoom in on the problem and zoom in on the people.

Do you have a great problem? Do you need a prototype to validate your idea, or are you ready to go to market? My role is not just to code, but to challenge assumptions, simplify scope, and keep you focused on outcomes that matter.

Problem. Prioritise. Then build.

Let’s talk about it!