How to Find a SaaS Idea: Start With a Problem, Not a Brainstorm

This guide is for the moment before an idea: you can build, maybe faster than ever with AI tools, and you have nothing worth building. If you already have an idea, our plan for what to do once you have an app idea is the better starting point. Sources were checked on November 7, 2026.

How to find a SaaS idea: the short answer

Find a problem first, and an idea second. A SaaS idea worth building has three things you can check before you write code: a specific group of people with a recurring problem, proof that they already spend time or money working around it, and a way for you to reach them.

The two best-known pieces of advice agree. Paul Graham opens his essay How to Get Startup Ideas with: "The way to get startup ideas is not to try to think of startup ideas. It's to look for problems, preferably problems you have yourself." Y Combinator partner Jared Friedman, in YC's talk How to get startup ideas, names starting with a solution instead of a problem as one of the four most common mistakes.

Both are worth reading. The four steps below turn that advice into a process you can run over the next two weeks.

Allow about a week of evenings for steps 1 to 3, and another week for step 4. The numbers in this guide (30 rows, 10 candidates, 20 people) are working targets, not rules from research.

I want to build something but have no ideas

You are in good company. One founder put it this way on r/vibecoding: "building got easy. noticing something actually worth building didn't." Another, on r/SaaS, said every brainstorm produced either "massive SaaS ideas that require a huge team, or generic tools that already have 100 alternatives."

That is what brainstorming produces. Graham calls the results "made-up" or "sitcom" startup ideas: ideas that "sound plausible enough to fool you into working on them." YC has its own name for the most common kind, a "Solution In Search of a Problem", and Friedman's warning is that "usually, you never actually find the problem."

The fix is to change what you look for. One reply in an r/SaaS thread said: "Stop brainstorming. Brainstorming generates ideas that sound plausible. What you want is evidence of a workaround." A reply in another recommended looking for "people who already spend money and regularly complain about a problem."

A workaround is the most useful thing you can find, because it proves two things at once. The problem is real, since someone bothered to patch it. And it costs something, since the patch takes their time or their money.

Step 1: inventory your skills, access and the workarounds you see

Before you search anywhere, write one page with three columns. It decides where you look, and it stops you from searching the whole internet for a problem.

What you can build. Be specific: "web apps with logins", "browser extensions", "anything with an API and a scheduled job". AI app builders made this column longer, which is why it is no longer the scarce part.

Who you can reach. The column most builders skip, and the one that matters most. List the groups where 20 people would answer your message this week: former colleagues, a relative's trade, a community or hobby forum you are active in, past freelance clients. Friedman's first and best recipe is to start with "what your team is especially good at" and look for ideas where those strengths give you an unfair advantage. He says about half of YC's most successful companies trace back to roughly that recipe.

Workarounds you have already seen. Go through every job, internship, side gig and hobby you have had. Friedman's question for each one is "what seemed broken?" Write down anything that looked like one of these:

• A spreadsheet next to the real tool. The team has software, but the actual work happens in a sheet someone maintains by hand.
• Copy and paste between two systems. Every week, someone moves data from one tool into another.
• A paid human doing a repeatable task. A virtual assistant, a part-time bookkeeper or a freelancer paid to do the same steps every week.
• Duct-taped automations. Five Zaps, a script on someone's laptop, a shared inbox with a rule nobody understands.
• "I export this to Excel every week." The tool almost does the job, and a person fills the gap.

Each entry here comes with a real person you can ask about it, which no brainstorm gives you.

Step 2: how to find a problem to solve, from three sources

Now look for evidence in one or two areas from your inventory, not everywhere. Three kinds of source are worth your time, because each shows pain with money or time already attached.

1. Reviews of tools people already pay for

Pick the tools a group already pays for and read their middle reviews: the 2- and 3-star ones. A 1-star review can be a billing dispute or a bad day. A 3-star review may come from a paying customer who stayed and explains what they do instead, something like: "Works fine, but we still have to export the bookings and rebuild the report by hand." The r/SaaS reply above recommends the same thing: 2 and 3 stars, on tools with real revenue, because the reviewer is a paying customer and often describes the workaround.

Where to read: G2 and Capterra for business software, the Shopify App Store, the WordPress plugin directory, the Chrome Web Store, and Apple's and Google's app stores. Reviews of add-ons are especially useful, because each one is a business telling you what the main platform does not do.

Why this source: it points at a budget. On business software and paid add-ons, the reviewer usually pays for the tool, and they are telling you where it fails them.

2. Job posts and freelance gigs where people pay for manual work

Search freelance marketplaces such as Upwork and Fiverr, and ordinary job boards, for repetitive work: "data entry", "virtual assistant", "spreadsheet", "Zapier", "update our CRM", "weekly report". Read what the poster wants done, in which tools, and how often. A post asking for, say, "4 hours a week moving orders from Shopify into our accounting sheet" is a problem description with a price on it.

Look for the same task posted again and again, by different businesses. One post is one company's mess. Twenty posts for the same job in the same tools is a pattern worth chasing.

Why this source: it is the strongest of the three, because it puts a price on the problem: a business is ready to pay a person to handle it, often every week. Before you count a post, check that the same job keeps being posted and filled. Software that does that job for less is an easy thing to explain.

3. Complaint threads where one role talks

Finally, read the places where one specific kind of person talks shop: a subreddit for bookkeepers, a Facebook group for clinic managers, a Slack community for agency owners, a trade forum. Search them for phrases like "is there a tool that", "how do you all handle", "I still do this manually" and "alternative to". Our idea validation tools guide covers searching Reddit and setting alerts so these come to you.

Why this source: it gives you the exact words people use, and it tells you who they are. Those words become your page headline in step 4. This source alone is the weakest of the three, because complaining is free. Treat a complaint as a lead to check against the other two sources.

What to leave out

Two popular sources are not on the list. Idea lists give you products with nobody behind them. Keyword tools show what people search for once they already want a solution, which is useful later, when you test demand, but they rarely show you a workaround.

Keep an evidence log

Put every useful find in one sheet, one row each. Two fictional example rows:

Aim for 30 or more rows before you move on. You will start to see the same job described by different people in different words, and that repetition is what step 3 runs on.

Step 3: come up with 10 SaaS ideas, then cut them to 1

Now, and only now, write ideas. Write 10, each as one line in the same shape:

[Who] currently [workaround], which costs them [time or money]. Software that [one main action].

For example: "Clinic front-desk staff currently export bookings and rebuild the owner's report every Monday, which costs them about 3 hours a week. Software that sends the owner the report automatically."

Every candidate must point at rows in your evidence log. If it can't, it is a brainstormed idea that slipped in. Then run all 10 through five filters, in this order. A candidate that fails one is out. Don't argue with the filter.

1. Evidence. At least three different people describe the problem, without being asked. One loud thread is not enough.
2. Money already moving. They pay something today to work around it: a tool, a freelancer, an assistant or a lot of their own paid hours. Graham's advice is blunt: "Make something unsexy that people will pay you for."
3. It recurs. The problem comes back every week or month. A one-time job is a weaker fit for a subscription.
4. You can reach 20 of them this week. By message, in a community you belong to or through someone who knows them. If you have no way to reach them, you do not yet have a way to sell to them.
5. You can build the main action alone in a few weeks. Only the one action that removes the workaround, not the whole product. Anything that needs a sales team, a hardware supply chain or a regulated data setup before the first user is out for a first SaaS.

If two candidates survive, keep the one with the most evidence in your log. If none survive, that is a finding too: go back to step 2, in a different area from your inventory.

Notice that "there are already competitors" is not a filter. Friedman's advice is to "err on the side of doing things with existing competitors", because founders who pick empty spaces "usually find out that the reason there are no competitors is because nobody wants the product." Paying customers of competitors are evidence of a budget. Their 3-star reviews can tell you what those tools miss.

A worked example of the 10-to-1 cut

Here is how the cut looks for an imaginary builder who spent three years doing IT for a group of physiotherapy clinics. It is an illustration, not research.

Candidate 10 wins. It is not exciting, and that is fine. It has people, a workaround, money and a way in.

Micro SaaS ideas: where small problems hide

Micro SaaS usually means a small subscription product, run by one person or a tiny team, that solves one narrow problem for one group. The method above suits it well, because the filters favor small, recurring, reachable problems over big ones.

Two places are especially good for micro SaaS:

• Add-on marketplaces. The Shopify App Store, the WordPress plugin directory, the Chrome Web Store and other platforms' app marketplaces are both a source of evidence (their reviews) and a way to reach buyers (their search). Rob Walling, in his essay The Stair Step Approach to Bootstrapping, argues for a first product with a simple marketing plan, "one that only requires a single traffic channel", and calls it "much easier to sell an add-on to an existing ecosystem", naming "a WordPress plugin, a Shopify app" among his examples.
• Boring back-office work. Reports, reminders, reconciliations and exports. These are the jobs that show up again and again in freelance posts, when existing tools still leave that group doing the work by hand.

What we don't recommend is picking from a list of micro SaaS ideas. A list gives you the solution and leaves out the person, the workaround and the money.

Step 4: test the winner in 7 days

You are not building yet. You are finding out whether strangers want the one thing your winner promises. This is the short version; the full method is linked below.

1. Write one promise in the words from your evidence log: "Your weekly booking report, in the owner's inbox every Monday, without the export."
2. Put up a waitlist page with that promise as the headline, one line on the problem, a signup form and one optional question, such as "How do you handle this today?"
3. Write down your signup number before you share the page. How many people you don't know must sign up this week for you to keep going? A number chosen afterwards always looks good enough.
4. Share it with the 20 people from your reach list and in the communities from step 2, following each one's rules on self-promotion.
5. On day 7, compare the result with your number: build, rewrite the promise, or go back to your list of 10. A signup shows interest, not willingness to pay. Talk to the people who joined before deciding to build.

For the full version, see the 14-day plan for once you have an idea, which includes a suggested signup bar, and our idea validation tools guide, which covers the seven methods with tools for each. The customer discovery interview questions help you talk to the people who sign up, and how to pre-sell a SaaS covers asking for money before you build. For a quick gut check, try the free startup idea validator.

Mistakes that keep builders without an idea

• Counting complaints instead of workarounds. A complaint costs nothing. A spreadsheet someone maintains every week, or a freelancer someone pays, costs something.
• Waiting for a brilliant idea. Friedman points out that Google was "like, the 20th search engine" when it started. A good enough starting point that you test beats a brilliant one you keep thinking about.
• Building first because building is easy now. AI tools shortened the build. They did not shorten the time it takes to find people who want what you built. If you have already built something, our guide for after you build an app with AI covers finding your first users.

Where LaunchList fits

Disclosure: LaunchList is our product. It is pre-launch waitlist software for founders, and it covers step 4 of this method. It does not find ideas for you, and it does not replace the evidence log or the conversations.

• A page from one sentence. Describe your idea and the AI writes a waitlist page you can edit and publish at its own launchlist.page address. Paste in the promise from your evidence log and keep the words your future customers used.
• One question on the signup form. Add an optional question, such as "How do you handle this today?" The answers tell you about their workarounds.
• A signup count you can check against your number. Every signup lands in one list, so day 7 is a comparison, not a guess.

The page, the AI that writes it, the form question and the signup list are all on the Free plan, which holds 100 contacts. During the beta, AI is included on every plan, subject to fair use. To see what else the page can do, start with the waitlist landing page builder.