Niche discovery: finding a worthwhile narrow market
A "niche" is a small group of people that's specific enough, shares a common pain point, and that you can reach repeatedly. Pick the wrong niche and the best execution won't save you; pick the right one and even a mediocre product can survive. This is one of the highest-return decisions in the whole chain.
Why "go narrow" instead of "go broad"
The most common beginner mistake is trying to build a product "for everyone." But as an indie developer with no budget and no team, going broad is a dead end:
- You can't say who it's for: "a project management tool for all businesses" vs. "an appointment management tool for dental clinics" — with the latter, a potential customer instantly knows "this was built for me."
- You can't outgun the big players: broad markets are full of well-funded giants, and you'll lose on ad bids and SEO alike.
- You have no idea where to market: only once you're narrowed down to a specific group do you know which forum to go to, who to follow, and what to write.
How to judge a good niche
A niche worth pursuing ideally meets all of these (you don't need every one, but the more the better):
| Dimension | The question to ask yourself |
|---|---|
| Strong pain point | Is this problem a "headache bad enough to go looking for a cure," or a "nice to have, fine without it"? People only keep paying for the former. |
| People are already spending money | Is this group already paying to solve a similar problem (even with Excel, outsourcing, or duct-taped tools)? Existing budget is best. |
| You can reach them | Where do they gather? Is there a community/platform/search term you can get into and feel at home in? Can't reach them = can't sell to them. |
| You have relevance | Do you understand this domain? Are you a practitioner, an enthusiast, or do you have an information edge? Relevance brings trust and insight. |
| Right-sized | Big enough to sustain a small business, small enough that the big players can't be bothered to build for it specifically. "Narrow and deep" is the sweet spot. |
Where to find a niche: four real sources of demand
1. Your own pain points and workflow
Back to "scratch your own itch" from the last chapter. The things you do manually and repeatedly at work, in DevOps, and in daily life — the stuff that annoys you — are often the opportunity. You're both the user and the developer, so the validation cost is lowest.
2. "Complaints" and "asking for recommendations" in communities
Real pain points show up in public as complaints. Go to these places and search for keywords like "how do I / how to…", "is there a tool that can…", "any recommendations", "I'm sick of…":
Competitor bad reviews are a gold mine: the 1–2 star reviews of existing products are, line by line, a checklist of needs that aren't being met. "It's great in every way, it just doesn't have feature X / is too expensive / is too complex for a small team" — that's your way in.
3. Search demand (keywords)
The words people type into the search box are the strongest signal of intent. Checking whether a term has search volume and how competitive it is tells you whether the market exists. Developers have a natural advantage here (programmatic SEO, covered later). Common tools:
4. Trends and the "gold rush" of new platforms
Whenever a new platform or technology appears (a new AI capability, a new API, a new hardware ecosystem), there's a brief window of "lots of demand, little supply." Pieter Levels's PhotoAI and Interior AI hit exactly the early window of generative AI. Developers are sensitive to new tech, and that's another of your advantages — but watch out for fake opportunities that just chase hype with no real, sustained demand.
Write the niche as one sentence
Once you have a direction, use this template to compress it into one clear piece of positioning (we'll deepen this in the "marketing frameworks" chapter):
I help [specific group] solve [specific pain point], so they can [outcome they achieve].
e.g.: I help "indie developers" solve "having to rebuild auth and payments every time before launching a SaaS," so they can "ship a paid product in days."
If this sentence contains "everyone," "any business," or "all kinds of needs," it's not narrow enough yet — go back and cut again.
What to remember from this chapter
- Go narrow, not broad: get specific down to a small group where you can clearly say "who it's for."
- A good niche = strong pain point + people already spending + you can reach them + you have relevance + right-sized.
- Demand signals hide in: your own pain points, community complaints, competitor bad reviews, search terms, and new-platform windows.
- Compress the direction into one sentence: "I help [who] solve [what]."
Now that you have a direction, don't rush to open your IDE. The next chapter is the step developers skip most often but should value most: validating demand before you write code.