How to Find Your Next SaaS Idea: A Framework for Indie Hackers

Every week, a new founder posts in an indie hacker community asking for SaaS ideas. Every week, the same problem: they do not need more ideas — they need a better method for finding ideas that are actually worth building.

The founders who consistently generate strong opportunities are not sitting in cafes waiting for inspiration. They run a deliberate process. It takes time, it involves talking to real people, and it produces a short list of ideas with genuine evidence behind them rather than a long list of guesses. Here is that process.

Why Most Idea-Hunting Advice Is Wrong

The conventional advice is to “scratch your own itch” — build something you personally need. This advice is not wrong, but it is incomplete. It only works if you happen to be in a market where others share your exact problem and are willing to pay for a solution. Many solo founders operate in markets — software development, content creation, personal productivity — where the competition is already intense or where the audience expects free tools.

The second piece of conventional advice is to browse Product Hunt, Indie Hackers, and Twitter for ideas. This is how you end up building the same note-taking app, AI writing tool, or Notion template pack that 200 other people built last quarter. These are not bad ideas. They are crowded ideas with established incumbents, price-compressed markets, and saturated acquisition channels. As a solo founder competing on time and attention rather than budget, crowded is the worst place to be.

The third mistake is ideating in a vacuum. Founders sit alone, think hard, and generate ideas from their imagination rather than from observed reality. Imagination produces features. Observation produces businesses. The distinction matters because features solve problems you invented; businesses solve problems that already exist and that real people are already trying to solve by other means.

The 4 Best Sources of Real SaaS Ideas

These four sources consistently produce opportunities that meet the core criteria: real pain, willingness to pay, and a reachable market.

Your professional history. Every job you have had involved tools, workflows, and processes. Most of those were broken in specific, documented ways. A 3-year stint in logistics, legal services, healthcare administration, or construction gives you domain knowledge that a generalist developer does not have. That knowledge is a competitive advantage worth exploiting. List the 10 most painful, repetitive workflows from your last two jobs. Each one is a research target.

One-star software reviews. Go to G2, Capterra, or Trustpilot and search for the dominant tool in any niche you understand. Sort by one-star reviews. Read 50 of them. You are looking for a pattern — a complaint that appears in 15 out of 50 reviews, something the software does badly or expensively that users cannot work around. That pattern is a product brief. Build the focused tool that does that one thing better and cheaper.

Niche online communities. Reddit, Facebook groups, Discord servers, and Slack communities organized around specific professions or industries are the most underused idea source available to indie hackers. Join 5–10 communities in a domain you want to explore. Spend two weeks reading posts without posting yourself. Search for “wish,” “anyone know a tool,” “we built a spreadsheet,” and “manual process.” These phrases signal a gap between the problem and available solutions. A community of 25,000 bookkeepers complaining about the same invoicing edge case every month is a market.

Your own tool stack. Every tool you pay for is either earning its price or failing to. The ones that are failing — that you use despite disliking, because no better alternative exists — are products waiting to be disrupted. Make a list of every subscription you pay for. For each one, ask: what would I remove from this product and sell as a standalone tool at half the price? What is this tool doing badly that I cannot change? Some of these will be too competitive to enter. Some will have viable niches hiding in them.

The Idea Evaluation Framework

Once you have a list of 10–15 potential ideas from the above sources, run each one through this evaluation before committing any development time.

Problem frequency. How often does this problem occur for the target user? A problem that happens once a quarter does not generate urgency. A problem that recurs weekly or monthly is something people will pay to eliminate. Score each idea: daily/weekly = high, monthly = medium, quarterly or less = low. Deprioritize anything scoring low.

Existing spend. Is there already money being spent to solve this problem, even imperfectly? Existing spend — on janky tools, freelancers, manual processes, enterprise software with overkill features — proves willingness to pay. No existing spend means you will have to educate the market that the problem is worth solving. That is a much harder job and not one well-suited to a solo founder with limited runway.

Reachability of customers. Can you find and reach 100 potential customers within one week using only free channels? This means: is there a subreddit, a professional association, a LinkedIn group, a job board niche, or a conference where these people gather? If you cannot identify a clear, reachable channel in 10 minutes of searching, distribution will be your blocker even if the product is excellent.

30-day buildability. Can you build an MVP that proves the core value in 30 days, working 2–3 hours per day? If not, simplify the scope until you can answer yes. The risk of investing 6 months before getting user feedback is too high for an unvalidated idea. Constrain the scope to the single most valuable workflow and build that first.

Ideas that score well on all four criteria are worth moving to a validation step. Ideas that fail two or more criteria should be deprioritized regardless of how exciting they feel.

For a deeper look at this type of narrow positioning, the article on micro SaaS ideas for indie hackers covers how specificity drives every aspect of early traction — from acquiring your first 10 customers to pricing your product effectively.

Going From Idea to First Paying Customer

A validated idea still requires a path to revenue. Here is the shortest path.

Before building anything, find 10 people who match your target customer profile and ask if you can ask them about their workflow around the problem you identified. Do not pitch a product. Ask about the problem: how often it occurs, what they currently do about it, what that costs them in time or money, and whether they have tried any tools to solve it. If 7 out of 10 describe the problem as significant and expensive, you have enough signal to proceed.

Build the smallest possible version that delivers the core value. Not a landing page — a working tool. At this stage, design does not matter. Reliability and the core workflow matter. Your MVP should do one thing, do it reliably, and have a way to collect payment.

Charge from day one. Do not launch a free tier, a free trial, or a “sign up and we will email you.” Ask the people you interviewed if they want to pay $X/month to be among the first users. If they say yes, take their money. Paid users give you honest feedback. Free users give you polite feedback.

Your first 5 paying customers will almost certainly be people you reached through direct outreach — a cold LinkedIn message, a reply in a community thread, a personal email to someone you interviewed. That is fine. Direct outreach is how early revenue happens. Do not wait for inbound.

Once you have 5 customers, talk to all of them. Ask what they were doing before your product, what they would do if it disappeared tomorrow, and what the single most important improvement would be. The answers will tell you where to go next more reliably than any analytics tool.

The full pre-launch process — from idea to confirmed paying customers — is covered in the guide on how to validate your app idea before building. It walks through the exact steps between “I think this could work” and “here is the evidence that it does.”

Finding a SaaS idea is not the bottleneck. The bottleneck is finding an idea with real evidence behind it and having the discipline to validate before building. The founders who do that consistently build businesses. The rest build features.