How to come up with SaaS ideas in 2026

Almost every founder starts the same way: staring at a blank doc, waiting for a good SaaS idea to arrive by inspiration. It rarely does, and when it does, it's usually untested — a guess dressed up as a plan. The founders who consistently land on ideas worth building skip the blank doc entirely. They go read where people are already complaining, comparing tools, and asking for something that doesn't exist yet, and they build from there.

Great ideas are found, not brainstormed

Brainstorming has a structural flaw: it starts inside your own head, where you have no evidence, only intuition. You can list a hundred plausible SaaS ideas in an afternoon and every one of them will feel reasonable, because "reasonable" is a low bar when nobody's pushing back. The problem shows up later, after you've built something, when you go looking for customers and discover the pain you imagined isn't the pain people actually have — or it is, but nobody's frustrated enough to pay to fix it.

The alternative is to treat idea generation as a research problem, not a creative one. Instead of asking "what could I build," ask "what does the evidence say people already want built." That single shift — from invention to observation — is the difference between founders who spend months validating a guess and founders who spend a week confirming a pattern they already found in public.

Start from demand, not from your feelings

Every market leaves a trail before anyone builds the product for it. People don't wait for a solution to exist before they start describing the problem — they post about it, ask for recommendations, hack together spreadsheets, and complain in reviews of the closest thing they can find. That trail is public, timestamped, and free to read. It's also almost entirely ignored, because reading a few hundred forum threads is less fun than sketching a landing page.

This is where BuyerTell and manual idea-mining share the same philosophy: the market has already told you what it wants. Your job isn't to invent a want, it's to notice the one that's loudest, most specific, and most obviously tied to money. Demand you can point to beats demand you can imagine, every time.

For a deeper walkthrough of where this trail actually lives online — beyond the five sources covered below — see where to find SaaS ideas.

The 5 places demand leaves a trail

Not every corner of the internet is equally useful for this. Some communities are full of opinions with no money behind them; others are full of people who run businesses and already pay for software. These five sources consistently produce the highest-signal evidence:

1. Reddit's professional subreddits. Communities built around a job, not a hobby — accountants, agency owners, e-commerce sellers, IT admins — surface pain from people who already spend money to run their business. A complaint here carries more weight than the same complaint on a general-interest subreddit. See our breakdown of the best subreddits for finding SaaS ideas for a working list.
2. Hacker News. Technical, opinionated, and full of builders describing their own workflow gaps — often in enough detail that the idea brief practically writes itself. "Show HN" comment threads are especially useful, because commenters critique what's missing from an existing product.
3. Stack Exchange's softwarerecs tag. A tag entirely made of people asking "is there a tool that does X." This is about as close to raw solution-seeking demand as you'll find in one place — every question is implicitly a feature request for a product that doesn't exist yet, or isn't known.
4. App Store 1-2 star reviews. Reviews of existing paid apps, filtered to the low end, are a goldmine of switching intent. These are people who already pay for something in the category and are unhappy enough to say so publicly — read closely and you'll see exactly which feature or price point is driving them away. More on this in turning App Store reviews into product ideas.
5. GitHub Issues. Feature requests with dozens of thumbs-up reactions on open-source tools are a direct, unfiltered look at what technical users wish existed. If a request has been open for years with steady engagement and no maintainer action, that's a strong tell the market is underserved.

BuyerTell adds a sixth source, Lobsters, to this list, and mines all six every day so the pattern-spotting is already done by the time you see it — but the underlying method works identically whether a machine or a person is doing the reading.

Read the buyer's tell: intent beats complaints

Not every post that mentions a problem is worth the same amount. A tired complaint and an explicit statement of willingness to pay look similar on the surface — both are text on a page — but they predict completely different outcomes. Learning to read the difference is the single highest-leverage skill in this whole process. For the full framework, see what is buyer intent and the phrases that predict willingness to pay.

Roughly, in order of strength:

• Willing to pay (weight ≈ 1.8×). Explicit language — "would pay for this," "take my money," "shut up and take my wallet." Rare, and the closest thing to a purchase signal that text gets.
• Switching (≈ 1.5×). "Alternative to [tool]," "canceling because," "looking to switch from." These people already pay in the category — the hardest part of a sale is already proven.
• Solution-seeking (≈ 1.35×). "Is there a tool that…," "what do you use for…" Active, present-tense searches with high commercial intent, though no confirmed price point yet.
• Workaround (≈ 1.2×). "I built a spreadsheet for this," "hacked together Zapier and three apps." Real effort spent solving the problem badly — a strong tell that a proper version would get adopted.
• Pain (≈ 1.0×). "So tedious," "someone should build this." Genuine frustration, but the weakest confirmed signal of willingness to pay — treat it as a lead, not a conclusion.

The gap between the top and bottom of that ladder is enormous. A handful of "take my money" comments should outweigh a hundred generic gripes in how you prioritize — and most people mining ideas manually never make that distinction, which is exactly why they end up chasing loud but low-value pain.

The market has already told you what to build. Most founders never read the signal — they invent a solution first and go looking for validation second.

Score before you fall in love

Once you've collected raw signal, resist the urge to just pick your favorite. A simple mental model keeps you honest: score = engagement × intent × source. Engagement is upvotes, replies, and reactions — proof other people share the pain, not just the one person who posted it. Intent is where the post sits on the ladder above. Source weight accounts for who's talking — a thread of small-business owners complaining is worth more than the same volume of comments from students or hobbyists with no budget.

This is the exact scoring logic BuyerTell runs on every signal it pulls, deduplicated and capped per source so one prolific poster or one viral thread can't dominate the ranking on volume alone. If you're doing this by hand, keep a spreadsheet, apply the same multiplier logic consistently, and be honest about the weighting — it's tempting to inflate the score of an idea you're already emotionally attached to.

From signal to idea brief

A pile of scored signals isn't an idea yet — it's raw material. The step that turns it into something buildable is writing an actual brief, with four parts:

• Pain. What, specifically, is broken or missing? Quote the evidence directly rather than paraphrasing — the exact words people use are usually your best marketing copy later.
• Who pays. Which role or business actually controls the budget for this? "Agency owners" is a payer; "creative people" usually isn't, because nobody with that title has a line item for your product.
• Why now. What changed recently — a price hike from an incumbent, a platform policy shift, a new API, a shift in how people work — that makes this the right moment rather than five years ago or five years from now?
• MVP. The smallest version of the product that delivers the core outcome, stripped of every feature that isn't load-bearing to the pain you found evidence for.

This is the format BuyerTell uses to hand back three ranked briefs every morning — each one grounded in the actual quotes it scored, run through Claude Opus 4.8 to synthesize the pain, payer, timing, and MVP into something you can act on the same day, rather than a vague theme you'd still have to research yourself.

Validate in a week

A high score on paper is still a hypothesis. Before you write a line of product code, spend a week — not a quarter — turning it into real evidence, using experiments that cost almost nothing:

• Landing page + waitlist. Write the one-sentence pitch, put up a page with a single CTA, and send a small amount of traffic to it from the same communities where you found the signal. A 3-5% email conversion from a cold, relevant audience is a genuinely good sign.
• Concierge MVP. Do the job manually for three to five real people before writing software. If the workflow isn't valuable enough for someone to pay you to do it by hand, it isn't valuable enough to build a product around.
• Fake door. Add a "coming soon" button somewhere relevant and measure the click-through rate. It's the fastest way to test demand for a specific feature without building it, as long as the audience is honest and already relevant to the problem.

For the complete list of experiments — including how to pre-sell before the product exists and how to DM the people whose posts you originally scored — see the full guide to how to validate a SaaS idea before you build it.

The takeaway

Coming up with a SaaS idea isn't a moment of inspiration you're waiting for — it's a repeatable process of reading evidence, weighting it honestly, and confirming it cheaply before you commit real time to it. Start from the five places demand already lives, learn to tell a "would pay for this" from a generic complaint, score what you find instead of trusting your gut, and write a brief with a pain, a payer, a reason it matters now, and a minimum build. Doing this manually works — it just takes hours every week that most founders don't have. If you'd rather skip the scrolling, compare how tools that automate this stack up in our SaaS idea tool alternatives comparison.

FAQ

How do I come up with a SaaS idea?

Don't invent one — find one. Read where people already describe problems in public: professional subreddits, Hacker News threads, Stack Exchange's softwarerecs tag, 1-2 star App Store reviews of tools they already pay for, and GitHub issues with heavy upvotes. Score what you find by engagement, buyer intent, and source quality, then turn the highest-scoring pattern into an idea brief with a clear pain, payer, and reason it matters now.

Where do the best SaaS ideas come from?

The best SaaS ideas come from public evidence of unmet demand, not brainstorming. Reddit's professional subreddits, Hacker News, Stack Exchange softwarerecs, App Store 1-2 star reviews, GitHub Issues, and Lobsters are six of the richest sources, because people posting there are describing real, timestamped pain in their own words.

How do I know if a SaaS idea is good?

A SaaS idea is good when there's evidence someone would pay for it, not just use it. Look for explicit willingness-to-pay language, people switching away from an existing tool, active solution-seeking, or manual workarounds — then confirm it with a cheap, week-long experiment like a landing page and waitlist, a concierge MVP, or a pre-sale before you write any code.

Do I need an original idea?

No. Originality is not what makes a SaaS idea succeed — evidence of demand is. Most successful SaaS products serve a problem other tools already address, just for a narrower audience, with a better workflow, or at a fairer price. A well-validated, unoriginal idea beats an untested original one almost every time.