The Developer's Money Handbook
Getting Started · Chapter 2

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.
Real proof: Liinks (Charlie Clark, ~$25K/month) link-in-bio (personal page aggregators) is a heavily saturated market dominated by giants. Charlie didn't try to "innovate and disrupt" — instead he carved out a narrow segment, drove costs rock-bottom, and made the experience excellent, cutting out $25K/month in a red ocean on "small and focused + low price." Proof: finding a neglected little corner in a big market is more realistic than discovering a new continent.Source: Indie Hackers interview with Liinks (see references)

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):

DimensionThe question to ask yourself
Strong pain pointIs 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 moneyIs this group already paying to solve a similar problem (even with Excel, outsourcing, or duct-taped tools)? Existing budget is best.
You can reach themWhere 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 relevanceDo you understand this domain? Are you a practitioner, an enthusiast, or do you have an information edge? Relevance brings trust and insight.
Right-sizedBig 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…":

Relevant subreddits on Reddit Industry forums / Discord / Slack groups Competitors' bad reviews (App Store, G2, Trustpilot) Hacker News / Indie Hackers threads Rant posts on X

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:

Google Keyword Planner (free) Google "autocomplete / related searches / People also ask" Ahrefs / Semrush (paid, with free-tier tools) Google Trends (for direction of the trend)

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.

!
Tell "interesting" apart from "in demand" The trap developers fall into most easily: building something technically cool that excites you but that nobody is actually in pain over. "Cool" doesn't equal "someone will pay." Every time you get excited about an idea, force yourself to answer: Who would pay for it? What are they making do with right now? Why would they have to switch to mine? If you can't answer, don't write code yet — go to the next chapter and validate.

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.