How to Find Business Ideas That People Will Actually Pay For

Now that you've chosen your business model — whether it's Micro-SaaS, consulting, info products, or dev tools — comes the part that feels like it should be easy: What problem am I actually going to solve?

Here's where most developers hit a wall. They've done the groundwork. They've thought about runway, hours per week, revenue targets. They've made a smart choice about their model. And then they sit down to think of ideas and... nothing that feels real emerges. They brainstorm. They sketch landing pages. They imagine launches. But if they're honest, none of it came from something they actually experience — it came from what sounds like a business idea.

That's not a creativity problem. It's a method problem. The fix is simpler than you'd think: stop generating ideas in the abstract. Start noticing problems in your actual work. The best business ideas don't come from inspiration. They come from friction. This section teaches you how to find that friction reliably, evaluate it honestly, and build a pipeline so you're never scrambling for "what's next."

The Trap: Why Inspiration is the Wrong Source

Paul Graham, who's watched more startup ideas fail than almost anyone, calls them "sitcom startup ideas."^[1] The term comes from a simple observation: if a TV show writer needed to come up with what a startup does, they'd have to invent something. They can't just ask founders, because that's not dramatic. So they'd come up with an idea that sounds plausible but is actually bad.^[2]

His example: a social network for pet owners. Millions of people have pets. Some spend a lot on them. Surely some would want to connect with other pet owners online. It sounds reasonable. When you mention it to someone with a dog, they nod and say "yeah, maybe I could see using something like that."

Here's where it breaks: "maybe I could see using that" is not demand. It's politeness.^[2] And developers, especially, are susceptible to confusing the two. We're used to building to spec — where "the spec says build this" stands in for "users actually want this." In a job, someone upstream has (theoretically) validated demand before writing the spec. When you're building for yourself, there's no one doing that work.

Sitcom startup ideas have tells:

• They start with a demographic ("pet owners," "remote workers," "freelancers") rather than a specific problem someone is having right now
• When you imagine the customer, they're a blur — you can't picture a specific person who needs this urgently
• The value prop is vague: "it connects people" or "makes X easier" without a concrete before/after
• You're already imagining the landing page before you've found a single person with the underlying problem

The fix isn't smarter brainstorming. It's logging the friction you actually experience.

Wells vs. Craters: The Shape That Works

Here's a piece of Graham's thinking that's counterintuitive but crucial. When you're evaluating an idea, there are two shapes of market you can target: something lots of people want a little, or something a few people want intensely. Pick the second one.^[2]

Visualize it: x-axis is people, y-axis is how much they want it. Google is an enormous crater — hundreds of millions of people use it, and they use it constantly.^[1] But no startup can dig that crater from zero.

You have two realistic starting positions: broad and shallow, or narrow and deep, like a well.^[2]

Sitcom ideas are broad and shallow. A social network for pet owners has wide reach but weak individual need. Nobody wakes up desperate for it.

Good indie developer products are wells. Maybe 10,000 people need exactly this thing. They need it badly. They'll pay, they'll tell others, they'll forgive rough edges in v1. Microsoft started as a well — making Altair Basic for a few thousand Altair owners who were otherwise stuck programming in machine language.^[1](http://paulgraham.com/startupideas.html) Facebook launched for Harvard students. A few thousand users, but they wanted it intensely.^[1]

As a solo developer, this is actually good news. You don't need a mass market. You need a small market with urgent need. And you're already sitting inside several of those markets — by virtue of being a working developer.

Remember: The goal is finding people who want your thing desperately, not people who might want it eventually. One person saying "I've been looking for something like this for months" beats fifty people saying "yeah, that sounds useful."

Where to Actually Look: Developer-Specific Friction Sources

The best ideas come from problems you have. Let's get specific about where developers encounter the most friction — and where that friction is actually shared by paying customers.

1. Tools You Wish Existed

This is the classic for a reason. What are you doing manually that obviously should have a tool? What tool do you use daily but find so clunky you've considered replacing it? What task do you handle with a Bash script, a Google Sheet, and optimism?

The key: it should be something actively annoying you right now, not a hypothetical inconvenience. If you've been tolerating a workflow for 18 months and have four workarounds, you've found something real.

2. The Painful Parts of Your Day Job

Look at last week's actual work. What took longer than it should? What did you have to explain to a colleague for the third time because documentation doesn't exist? What meeting could be an automated report? What deployment was stressful because the process is fragile?

Your day job is a paid research operation for business ideas. You see real problems, experienced by real people, in real professional context. You can't build on IP your employer created — but you can absolutely extract the insight about the problem and solve it yourself.

3. Workflows You've Already Automated for Yourself

This is underused gold. Most developers have a collection of personal scripts, automations, and tools they've built over years — things saving 20 minutes a week or making annoying processes bearable. These are validated ideas. You built them because the pain justified the effort.

Ask yourself: could 500 other developers also use this? If yes, you might already have your first customer (yourself).

4. Communities You're Already Part Of

Forums, Slack groups, Discord servers, subreddits — the communities you already read are filled with disguised problem statements. "Is there a tool that does X?" "What do you all use for Y?" "I've been doing Z manually, is there a better way?" You're not looking for demographics. You're listening for pain.

5. Things You Know That Others Are Paying to Learn

This is different — less about friction, more about expertise gaps. What do you know deeply that others in adjacent roles (junior developers, non-technical founders) consistently struggle with? The thing you've explained in ten Slack conversations is probably something people would pay to have properly documented or packaged.

Indie Hackers is full of examples of this pattern — solo founders building bootstrapped SaaS businesses by starting from a specific, well-understood problem they encountered professionally.^[3](https://www.indiehackers.com/) The pattern is consistent. The starting point almost always is: "I had this problem, I built it, I found out others had it too."

The Idea Matrix: Filtering What You Find

You've been logging problems. You have a list. Now you need to triage it, because not all friction justifies building a business around.

Use three filters:

Desirability: Do people actually want this? Not "would they use it if it existed" — do they want it right now? Would they switch from what they're using today? Would they pay before it's built? This is harder to know than it sounds. (The validation section coming next goes deep.) At this stage, the minimum bar is: can you find three real people with this problem who express genuine frustration about it?

Feasibility: Can you, solo, build a version that addresses the core need in a few weeks? This isn't about limiting yourself to trivial projects. It's about right-sizing the initial version. You don't need the full vision — you need the narrowest thing that delivers core value. Developers tend to either overestimate MVP complexity or underestimate how long even the "simple" version takes. Be honest.

Viability: Will people pay enough, in large enough numbers, to justify the effort? The calculation is rough at the idea stage, but basic math helps. If you're targeting 100 customers at $20/month, that's $2,000 MRR — solid for a side project, maybe not if it requires 20 hours weekly support. If you need $99/month from B2B customers and require 50 paying customers to replace your monthly salary equivalent, is that realistic given who's actually out there? You don't need a spreadsheet. You need a reality check.

Warning: Viability is where developers most often fool themselves. If your idea only works if you capture 0.001% of a "billion-dollar market," the market size is doing zero work. Think about specific people you can reach and what they'd actually pay, not theoretical TAM.

How to Evaluate Competition Honestly

A common mistake: treating competition as a dead-end. "Oh, something already does this — idea dead." Wrong.

Existing solutions prove the market exists. If developers pay for Datadog, that proves developers pay for monitoring tools. It doesn't mean there's no room for another with different trade-offs. If people use Notion, that doesn't mean there's no room for a focused, simpler alternative for a specific workflow.

You're not looking for "zero competition." You're looking for gaps in how existing solutions serve specific slices of the market.

The questions that matter:

• What do people complain about in reviews of existing tools?
• Who is underserved by the current leader (too expensive? too complex? wrong integrations? bad support for a specific workflow)?
• What would a different take look like — simpler, cheaper, more opinionated, tighter integrations with tools your user already has?

Tip: Read the one-star and two-star reviews on G2, Capterra, or ProductHunt for direct competitors. That's your product roadmap. Those aren't just complaints — they're a list of things people wanted badly enough to write about.

Competition worth worrying about: a well-funded, fast-moving team building the exact same thing with the exact same positioning for the exact same customer. That's different from "the market leader doesn't serve this niche well."

The Watering Hole Test

Here's a practical gut-check: can you find where this customer congregates online?

If you're targeting "developers frustrated with slow Postgres query debugging," you can probably find them. There are Postgres subreddits, Slack communities, Hacker News threads, forum posts from people describing exactly this frustration.

If you're targeting "small business owners who want better invoicing," that's harder. The customer is diffuse. There's no natural gathering place. And if you can't find them now, reaching them later for customer acquisition will be brutal.

This isn't about marketing yet. It's about signal. If you can name three specific communities where your target customer is already asking questions about the problem you want to solve, that's strong early evidence:

1. The problem is real
2. You can find customers
3. There's a community you can learn from

If you can't point to any specific community, that's worth taking seriously.

Idea Journaling: Building a Pipeline Instead of Playing the Lottery

Here's the shift that separates developers who reliably find good ideas from those who feel stuck: treat idea generation as ongoing practice, not a one-time event.

Most developers approach this as a crisis ("I need an idea now"). That's lottery thinking. Idea journaling is the alternative.

The practice: any time you notice friction — in work, in a tool you use, in a conversation, in a community — write it down. Not a solution. Just the problem. Date it. One sentence.

After a few weeks, you have a list. Some is noise. Some will reveal a pattern: a problem that keeps appearing, that other people share, that you keep thinking about, and that nobody's solved cleanly.

The discipline is recording problems as they happen, not during a brainstorming session. The best ideas are usually in your log from three months ago, not something you invented during a two-hour strategy meeting.

Log these specifically:

• Manual workarounds: "Had to X manually again because Y tool doesn't support Z"
• Repeated questions: "Another person asked me how to do X today — fourth time this month"
• Things that took too long to explain: "Spent 45 minutes explaining this — no good resource exists"
• Things you built for yourself: "Made another script for X — feels like a product"
• Online complaints: "Thread with 200 comments all hating on [tool] for [specific gap]"

You're not aiming for 200 ideas. You're aiming for a handful of well-observed problems you've seen from multiple angles. One deeply understood problem beats 50 half-formed hunches.

Putting It Together: What a Good Idea Actually Looks Like

Here's the shape of a good developer side business idea:

• It comes from a problem you've experienced directly, more than once
• You can name at least one other person (ideally five) who has the same problem
• Existing solutions either don't exist or are clearly insufficient for this specific use case
• The person with this problem is findable — you know where they congregate online
• The problem is annoying enough they'd pay to fix it (they've probably already paid for partial solutions)
• You can build a version addressing the core need in a few weeks, not months

That's it. You don't need a novel idea. You don't need to invent a new category. You need a real problem, a specific customer, and a gap in what exists.

If you take one thing from this section: Stop trying to think of ideas. Start logging problems. The difference between those two activities predicts most of the variance in whether what you build ever gets paid for.

Recap — three things to remember

1. Ideas from imagination produce sitcom startups; ideas from observed friction produce real businesses
2. Choose narrow and deep over broad and shallow — find people who urgently need your thing, not people who might eventually want it
3. Idea journaling builds a pipeline; competition in a market is evidence demand exists, not a reason to walk away

Sources cited

1. Paul Graham, who's watched more startup ideas fail than almost anyone, calls them "sitcom startup ideas." paulgraham.com ↩
2. The term comes from a simple observation: if a TV show writer needed to come up with what a startup does, they'd have to invent something. They can't just ask founders, because that's not dramatic. So they'd come up with an idea that sounds plausible but is actually bad. paulgraham.com ↩
3. Indie Hackers is full of examples of this pattern — solo founders building bootstrapped SaaS businesses by starting from a specific, well-understood problem they encountered professionally. indiehackers.com ↩