Forget SaaS ideas. Find market signals.

LeoWade — Thu, 08 Oct 2026 12:58:32 +0000

A lot of first-time founders make the same mistake when they start building SaaS for the global market.

They ask:

Where should I look for good product ideas?
Can I trust complaints on Reddit?
Should I copy SaaS products that are already making money on TrustMRR?
If people are hiring freelancers on Upwork, does that mean the problem can become a software product?
If a keyword is trending on Google Trends, does that mean there’s an opportunity?

None of these approaches are wrong.

The mistake is expecting any single platform to give you the “right answer.”

I spent about a month going down different paths, testing different ways of finding opportunities, and making plenty of wrong turns.

Eventually, I came to one conclusion:

Good software opportunities don’t live on one platform. They appear where multiple market signals overlap.

I summarize the whole process as:

5 Entry Points → 4 Proof Points → 1 Test

The five entry points are simply five different ways to detect market signals.

1. Money-first: Start With Products That Already Make Money

Look at TrustMRR, Acquire, established SaaS products, and competitor pricing pages.

Ignore user complaints for a moment and ask one practical question:

Are people already paying in this market?

This matters because many real problems are still bad businesses.

Developers may complain every day about an annoying Git workflow, but still only be willing to install a free plugin.

Meanwhile, some boring B2B tool may quietly have customers paying $49, $99, or several hundred dollars every month.

That’s why revenue data matters.

Its job isn’t to tell you what to copy.

Its job is to help you filter out problems that may be real, but have very little commercial value.

2. Search-first: Start With Growing Search Demand

Look at Google Trends, Keyword Planner, Ahrefs, and other keyword tools.

If more and more people are searching for terms like:

AI code review
AI documentation generator
GitHub code explanation

that tells you something important:

More people are becoming aware of the problem and actively looking for a solution.

This approach works especially well for SEO-driven products, utility tools, developer tools, and self-serve consumer SaaS.

But high search volume does not automatically mean high business value.

“PDF to JPG” might have huge search volume and brutal competition.

A very specific PostgreSQL migration problem might have tiny search volume, but each customer could be worth hundreds of dollars.

Search proves that people are looking. It does not prove that they are willing to pay.

3. Pain-first: Start With Complaints

Look at Reddit, GitHub Issues, Hacker News, Discord, and niche communities.

This is where you often discover problems that don’t even have a proper name yet.

A user probably won’t search for:

“AI Coding Intent Preservation Tool.”

They’ll say something like:

“Every time Claude changes my code, it forgets why I designed it this way.”

That sentence may be worth more than a list of 100 startup ideas.

Why?

Because genuinely new opportunities often exist before the market has invented a standard keyword for them.

But community complaints come with one major warning:

People who complain are not necessarily people who will pay.

4. Job-first: Start With Work People Already Pay For

Look at Upwork and Fiverr.

See what companies and individuals are hiring people to do.

This is a stronger signal than a complaint, because the customer is no longer just saying:

“This is painful.”

They’re saying:

“I’m willing to spend $300 to get this solved.”

The most interesting question is:

Which human services can be turned into software?

Imagine you repeatedly see people paying for:

codebase documentation
legacy code analysis
GitHub project demo videos
README rewrites
architecture diagrams

Don’t immediately think about freelancing.

Ask instead:

Is 60% to 80% of this workflow repetitive?

If the answer is yes, there may be an opportunity to turn a service into software.

5. Change-first: Start With What Has Newly Become Possible

Every major shift creates a new opportunity surface.

New AI models. New APIs. New platforms. New regulations. New workflows.

Things that were impossible, unreliable, or too expensive a few years ago may suddenly become practical.

For example, having AI understand a repository with hundreds of thousands of lines of code used to be expensive and unreliable.

Now we have agents, long-context models, code indexing, AST analysis, and RAG.

That makes entirely new categories of products possible:

code understanding
automated documentation
AI code review
automatic product demos

But Change-first is also where founders fool themselves most easily.

Just because something can be built doesn’t mean anyone wants it.

Think of Them as Five Different Radars

These five approaches should not be treated as competing strategies.

They are five different radars:

TrustMRR → money

Google Trends → search intent

Reddit → pain

Upwork → real jobs and budgets

Technology shifts → what has newly become possible

The strongest opportunities usually appear on more than one radar.

That’s the key idea.

A single signal is interesting.

Several independent signals pointing to the same problem are much more meaningful.

Then Validate With 4 Proof Points

Once you find an interesting direction, move on to the second part of the framework.

1. Money

Are people already paying for solutions to this problem?

If nobody is paying, you need a very strong reason to believe they will start.

2. Gap

Are existing products still missing something important?

Maybe they’re too expensive.

Too complicated.

Built for the wrong customer.

Or perhaps the workflow breaks at one critical step.

3. Pain

Is that gap real, or did you invent it in your head?

Go back to Reddit, GitHub, forums, and communities.

Look for different users, at different times, describing the same problem.

4. Behavior

What are users doing today to solve the problem?

Are they:

hiring people?
copying and pasting things into ChatGPT?
writing their own scripts?
using spreadsheets?
stitching together multiple tools?

This is one of the strongest signals in the entire process.

The best SaaS opportunities often don’t ask users to do something completely new. They replace a bad workaround people are already using.

Finally: Test Before You Build

This is the step technical founders skip most often.

Even if every previous signal is positive, your solution can still fail.

You may find a market where companies are making money.

Users clearly have the problem.

Competitors clearly have weaknesses.

People are already spending money trying to solve it.

And you can still build a product that nobody wants.

Why?

Because:

A valid market does not automatically validate your solution.

So don’t immediately spend three months building the full product.

Start smaller.

Build a landing page.

Make a simple demo.

Offer a semi-manual version.

Or solve the problem manually for three customers first.

Then watch what people actually do.

Will they sign up?

Will they upload their data?

Will they book a demo?

Will they pay?

That behavior matters much more than someone saying:

“Yeah, I’d probably use this.”

The Whole Framework in One Sentence

If I had to reduce everything to one sentence, it would be:

Don’t look for ideas. Look for evidence.

The best software opportunities usually have several signals at the same time:

People are making money.

People are searching.

People are complaining.

People are already spending time or money trying to solve the problem.

And existing products still don’t solve it well enough.

Where those signals overlap, that’s where an indie hacker should start paying attention.

So the next time you find a “great idea,” don’t get excited too quickly.

First, check whether there’s money.

Then see whether demand is growing.

See what users are complaining about.

Understand what they’re already doing to solve the problem.

And finally, run the smallest possible test.

Ideas are cheap. Code is getting cheaper.

In the AI era, the expensive part is judgment:

Knowing which problems are actually worth solving.

DEV Community: LeoWade