Everyone has a system for finding SaaS ideas. Most of them don't work.
I know because I've tried them all. I've scrolled through "50 Micro SaaS Ideas" listicles at 2am. I've screenshot Reddit complaints thinking "someone should build that." I've brainstormed in Notion docs that never became anything.
After building 14 products as a solo founder, some making money, others collecting dust, I finally have a process that actually filters signal from noise. It's not complicated. But it's the opposite of what most "idea generation" content tells you to do.
Here's the full breakdown.
The problem with idea lists
Every week a new blog post drops: "30 SaaS Ideas for 2026." They all have the same structure. A generic problem statement, a one-line solution, maybe an estimated market size pulled from a Statista report.
These lists aren't useless. They're fine as a starting point. But they share a fatal flaw: they skip the part that matters. Finding an idea is maybe 5% of the work. The other 95% is figuring out whether anyone will pay for it, whether you can build it, and whether you'll still care about it six months in.
I've launched products from idea lists. I've also launched products from personal frustration. The "personal frustration" products did way better. Not because the ideas are better on paper, but because I understood the problem well enough to build something people actually wanted.
Step 1: Notice what wastes your time
The best SaaS ideas don't come from research. They come from paying attention to your own workflow.
Here's a real example. I run a network of 12 web properties. Each one needed backlinks to build domain authority. I was manually submitting to directories, tracking which ones were dofollow, checking DR scores, and following up on submissions. It was tedious.
So I built BacklinkRocket. Not because a blog post told me "backlink tools are hot." Because I was doing the manual work myself and knew exactly what the solution should look like.
Another one: I noticed that developer portfolio tools were either ugly, overpriced, or didn't include anything useful for showing off real metrics. So I built VibeCoders. A portfolio page with revenue tracking, project showcases, and built-in SEO.
Both of these started as personal problems. The difference between a personal problem and a random idea is conviction. When you've felt the pain yourself, you don't need to convince yourself the problem is real. You already know.
The exercise: For one week, write down every time you do something tedious or frustrating in your work. Don't filter. Don't judge. Just log it. At the end of the week, look at the list. The items you wrote down more than once are your best candidates.
Step 2: Go where people complain (and pay attention to the specifics)
Your own problems are a great starting point, but they're limited to your own experience. To expand the search, go where people talk about their pain.
Reddit is underrated for idea research. Not the big subreddits like r/SaaS or r/startups (too much self-promotion). The real gold is in niche communities. r/freelance, r/accounting, r/realtors, r/ecommerce. People in these subreddits aren't trying to sound smart. They're frustrated and looking for help.
Search for phrases like:
- "I wish there was"
- "is there a tool that"
- "I've been doing this manually"
- "any alternative to"
These are people describing a problem they'd pay to solve. That's validation before you've built anything.
G2 reviews are worth looking at too, and almost nobody uses them for idea research. Go to the 2-star and 3-star reviews of established SaaS products. These are people who tried a tool, found it lacking, but didn't hate it enough to leave a 1-star review. They're describing specific gaps. Those gaps are your opportunity.
Upwork job postings tell you what people are paying humans to do. If someone is hiring a freelancer to do a repetitive task, that task might be automatable. I've found three solid product ideas just by browsing Upwork categories I know well.
Support forums and community Slack groups for tools you use are also worth monitoring. When the same question gets asked every week, there's a product hiding in that question.
Step 3: Filter for money, not excitement
This is where most people get it wrong. They find a problem and immediately start building. But not every problem is worth solving as a business.
I use three filters:
Filter 1: Will they pay?
There's a massive difference between "I'd love a tool that does X" and "I'd pay $30/month for a tool that does X." People love saying the first one. The second one is rare, and it's the only one that matters.
A quick test: look at what they're currently spending to solve this problem. If they're paying a freelancer $500/month, they'd probably pay $50/month for software that does the same thing. If they're doing nothing about it, they probably won't pay for your tool either.
Filter 2: Is the market big enough?
You don't need a billion-dollar TAM. For a solo founder, you need maybe 1,000 people willing to pay $50/month. That's $600k/year. Plenty to build a life on.
But you do need to verify those 1,000 people exist and you can reach them. If your target customer is "left-handed accountants who specialize in cryptocurrency tax for nonprofits," the market might be too small. If it's "freelancers who need to send invoices," you'll drown in competition.
The sweet spot is specific enough to be findable, broad enough to be sustainable.
Filter 3: Can I build and maintain it?
Solo founders underestimate maintenance. Every product you launch needs bug fixes, customer support, updates when third-party APIs change, and occasional feature additions to stay competitive.
Before I build anything new, I ask: can I maintain this alongside everything else I'm running? If the answer is no, I either simplify the scope or shelve the idea.
Step 4: Validate with money, not opinions
Asking people "would you use this?" is almost worthless. People say yes to be polite. The only real validation is money changing hands.
Here's my validation process:
Stage 1: Landing page (1-2 days)
Build a single page that explains the product, shows a price, and has an email capture or "join waitlist" button. No product needed. Just the promise.
Drive a small amount of traffic to it. I use a mix of Reddit posts (genuinely helpful posts in relevant subreddits, not spam), Twitter, and sometimes a small Google Ads budget ($50-100).
If nobody signs up, that's a signal. Not a death sentence, but a signal. Maybe the positioning is off, or you're reaching the wrong audience.
Stage 2: Pre-sell or concierge (1-2 weeks)
If the landing page gets interest, go deeper. Offer to solve the problem manually for 5-10 people. Charge them for it. Even $20 is fine. The goal isn't revenue. The goal is to confirm that real humans will open their wallets for this solution.
When I built one of my idea databases, I started by manually curating 500 ideas and selling access for $29. People bought it. That told me the demand was real before I invested in building out the full 130,000+ idea database.
Stage 3: MVP (2-4 weeks)
Only after money changes hands do I build a real product. And even then, the MVP is minimal. One core feature, done well. Everything else comes later, if there's demand for it.
The order matters. Landing page first, then pre-sales, then MVP. Most founders do it backwards: they build for months, then try to sell, then discover nobody wants it. Flip the sequence.
Step 5: Use databases to accelerate research
Doing all of this from scratch for every idea takes time. One shortcut I've found useful is starting with databases of pre-researched ideas.
There are several out there. IndieHackers has a database of profitable SaaS businesses you can browse for patterns. MicroSaaSDB tracks products with $500+ MRR. My own product, ProvenTools, aggregates 130,000+ ideas from sources like Reddit pain points, G2 gaps, and Upwork job postings, so you can filter by niche instead of doing the manual scraping yourself.
The value of these databases isn't the ideas themselves. Ideas are cheap. The value is the filtering. When someone has already aggregated thousands of data points and tagged them by category, market size, or competition level, you skip the tedious scraping phase and go straight to evaluation.
But a database is a starting point, not a decision-maker. You still need to run the filters from Step 3. You still need to validate with real money. No database replaces talking to potential customers.
Step 6: The "10 customers" test
Before I commit to building anything beyond an MVP, I apply one final test. I call it the "10 customers" test.
Can I name 10 specific people or companies who would buy this product?
Not categories. Not "freelancers" or "SaaS founders." Actual names. People I can email, DM, or call. If I can't name 10, I probably don't understand the market well enough yet.
It's easy to convince yourself that "lots of people" have this problem. It's much harder to name ten of them. And if you can name ten, you have your first sales pipeline.
I've killed ideas at this stage. Good ideas that I was excited about. But when I sat down and tried to name ten buyers, I couldn't. That saved me months of wasted building.
Common mistakes I see (and have made)
I've built for developers when I should have built for businesses. Developers are hard customers. They'd rather build their own tool than pay for yours. Businesses have budgets and deadlines. They'll pay for a solution that saves them time.
I've also confused "interesting" with "profitable." Interesting problems are fun to solve. Profitable problems are boring to solve but expensive to ignore. The best SaaS businesses solve boring problems really well.
Then there's overcomplicating the MVP. Your first version should embarrass you a little. If it doesn't, you spent too long building it. Ship something small, see if anyone cares, then improve based on real feedback.
One more: skipping competitor research. If nobody else is solving this problem, that's usually a bad sign, not a good one. It often means there's no market. The best ideas have existing competitors doing it poorly. You don't need to be first. You need to be better at one specific thing.
And the biggest time sink of all is spending more time researching than testing. Research feels productive. It isn't, past a certain point. After a week of research, you should be building a landing page, not reading another blog post about idea validation.
The honest truth about finding SaaS ideas
After 14 products, here's what I actually believe: the idea matters less than your ability to execute on it, sell it, and stick with it through the boring middle phase where growth is slow and nobody cares.
The founders I've watched succeed didn't necessarily have the best ideas. They had adequate ideas and they just didn't quit. They shipped fast, talked to customers, and fixed things based on what people actually said.
So pick an idea that passes the filters, validate it with real money, build the smallest possible version, and then commit to it for at least six months before calling it a failure. That's the whole process. Not glamorous, but it works better than scrolling through listicles at 2am.
I'm building in public as a solo founder running 14+ web properties. Follow me on X/Twitter for daily updates on what's working, what's failing, and what I'm learning along the way.