Picking a niche when you already build things

Niche selection advice is usually written for people who cannot build, and it shows. It tells you to find a profitable market, validate demand, and then figure out how to make something — sensible advice when execution is the bottleneck. But if you can already build software or products, your situation is inverted: execution is your advantage, not your constraint, which means the danger is not failing to make something but making the wrong something extremely well. The skill that should be your edge becomes a liability when it lets you build an elaborate, polished product for a market that does not exist. Picking a niche when you already build is mostly about pointing a capability you already have at a problem that is actually real.

This changes the whole calculation. The question is not "what can I build" — you can build many things — but "which real problem is worth pointing my building at," and the failure mode is using the ease of building as a substitute for the harder work of finding genuine demand. Builders fall in love with the construction and skip the validation, then wonder why the beautiful thing they made has no customers. The rest of this is about choosing a niche in a way that uses the building advantage instead of being misled by it: starting from real understanding, respecting cost structure, and testing demand before pouring the skill in.

The advantage is obvious and real: when you can build, you can move from idea to working product faster and cheaper than someone who has to hire or outsource everything, which means you can test more ideas and iterate more quickly. You are not blocked on execution, so the whole expensive, slow part of bringing something to life is cheap for you. That genuinely is an edge, and it is why builders can run the kind of lean, multiple-attempt approach that finds a winner through iteration rather than betting everything on one guess. Used well, the ability to build is exactly what makes a portfolio of small experiments affordable.

The trap is the same capability turned against you. Because building is easy and enjoyable, it is tempting to start building before you have any evidence that anyone wants the result, and to keep building — adding features, polishing, refining — as a way of avoiding the uncomfortable work of finding out whether there is demand. A builder can spend months crafting something excellent that solves a problem no one has, and the very quality of the work makes it harder to admit it was the wrong thing. The trap is using construction as procrastination from validation. Recognizing that your strength is also your blind spot is the first step to choosing a niche well, because it tells you to be most skeptical exactly where you are most comfortable.

The best niches for a builder are usually problems you genuinely understand from the inside, because deep understanding of a problem is the one thing that is hard to fake and hard to copy. When you have lived a problem — in a job, a hobby, a previous business, a community you belong to — you know its texture: what is actually painful versus merely annoying, what existing solutions get wrong, what people would happily pay to avoid. That understanding is worth more than a clever idea, because it lets you build something that fits the real shape of the problem rather than a guess about it. A builder who deeply understands a niche has an advantage no amount of building skill alone can provide.

This does not mean you can only build for problems you have personally suffered, but it does mean that the further you get from real understanding, the more you must compensate with research and conversation. Building for a market you do not understand, on the strength of your building skill alone, is how you end up with a technically impressive product that misses what the market actually cares about. The understanding can be acquired — by immersing yourself in the problem, talking to the people who have it, doing the work yourself — but it cannot be skipped. Start from where you already understand deeply, and only move outward as far as you are willing to do the work to genuinely understand the new ground.

For a builder, there is a filter that should rule out whole categories of niche before market attractiveness even enters the conversation: can the thing run cheaply when usage is low? A niche can be genuinely profitable and still be the wrong one for a lean operation if serving it requires always-on infrastructure, heavy ongoing third-party costs, or significant upfront inventory. Those cost structures invert the advantage of being a builder, because they charge you continuously whether or not you have customers, turning a lean experiment into a standing liability. The most attractive market in the world is a bad niche if you cannot afford to serve it during the long period when it has no revenue.

This is why cost structure deserves to be an early filter rather than a late consideration. A builder's superpower is the ability to run many cheap experiments, and that superpower only works if the experiments are actually cheap to run — which depends entirely on whether the niche's cost structure sits near zero at idle. Favor niches you can serve with the heavy work happening on the customer's side, with digital goods, or with lean operations, and be wary of ones that demand a large standing bill before the first sale. Picking a niche whose economics fit a lean operation is not a constraint on ambition; it is what keeps you in the game long enough for the ambition to pay off.

Building something to solve your own problem is reliable advice for builders, and for good reason: you understand the problem completely, you can tell immediately whether the solution works, and you are guaranteed at least one genuine user. Many good products started exactly this way, as a builder fixing something that annoyed them and discovering that others had the same annoyance. As a starting point for a niche, "what problem do I have that I could solve" is one of the strongest prompts available, because it grounds the idea in real, felt experience rather than abstract market analysis.

But the rule has a limit worth respecting: your own itch is only a business if enough other people share it and would pay to have it scratched. Plenty of builders solve a problem that is genuinely theirs and genuinely niche to the point of being theirs alone, then mistake their personal satisfaction for market demand. The itch tells you the problem is real for at least one person; it does not tell you the market is real. So treat scratching your own itch as a great way to find a candidate, then do the validation work to confirm that the itch is widely shared and that people will pay to relieve it. The personal problem is the seed, not the proof.

A profitable niche you cannot reach is not a niche you can serve, and reachability is a factor builders systematically underweight because it is not a building problem. Some markets gather in places you can find and be useful in — communities, forums, search terms, networks — while others are diffuse, hard to identify, or locked behind gatekeepers and relationships you do not have. The ability to build the perfect solution is worth nothing if you have no path to the people who need it. Before committing to a niche, ask honestly whether you can actually get in front of its customers without a marketing budget you do not have.

Reachability also shapes how expensive it will be to grow. A niche whose customers cluster in findable places, or who actively search for solutions to their problem, can be reached through being useful and through search — channels available to a builder with more time than money. A niche whose customers are scattered and not searching requires paid acquisition or relationships to reach, which raises the cost of every customer and erodes the lean advantage. Favor niches you can reach through effort rather than budget, because for a builder, time-and-skill is the currency you have and money is the one you do not. The most buildable niche is worthless if it is also unreachable.

Builders are drawn to exciting, novel, technically interesting niches, and that instinct is often exactly wrong. Exciting niches attract other builders, which means more competition and more people racing to build the same clever thing; boring niches — unglamorous problems in unsexy industries — attract far fewer, which means real demand with little competition. The novelty that makes a niche exciting to build for is frequently the same novelty that means the market is unproven, while the boredom that makes a niche unappealing is often a sign of a stable, real problem people have been paying to solve for years. Boring is frequently where the money quietly is.

This matters doubly for a builder, because the building advantage is most valuable where competition is lowest. In an exciting, crowded niche, your ability to build is table stakes — everyone there can build — so it provides little edge. In a boring niche that other builders overlook, the same ability is a genuine differentiator, because you may be one of the few capable people paying attention to the problem at all. The discipline is to follow the demand and the lack of competition rather than your own excitement, which often means choosing the dull, real problem over the thrilling, speculative one. The best builder niches are usually the ones other builders find too boring to bother with.

The whole point of these filters is to get you to a small, cheap test before you pour your building skill into a niche, because the skill is precisely what is expensive to waste. Validating a niche does not require building the full product; it requires the smallest possible evidence that the demand is real — conversations, a landing page, a pre-sale, a manual version of the solution delivered by hand. A builder's temptation is to validate by building, but building is the costly part, so the smart move is to find the cheapest test that produces a real signal and run that first. Spend the building skill only after something has pulled.

Testing first also protects you from the builder's trap directly, because it forces the validation step you would otherwise be tempted to skip. If you make yourself find evidence of demand before you start building, you cannot accidentally spend three months crafting the wrong thing, because you will have learned it was wrong during the cheap test instead of the expensive build. The niche is not confirmed until something outside your own enthusiasm says yes — a real conversation, a real pre-order, a real sale. Treat the building skill as a precious resource to be deployed only against validated demand, and the test-first discipline becomes the thing that keeps your biggest advantage from becoming your biggest waste.

The standard advice to "niche down" is sound but easy to overshoot. Narrowing your focus to a specific kind of customer with a specific problem makes you sharper, easier to find, and more obviously the right choice for the people you serve — a tool for a clearly defined audience beats a vague tool for everyone. Specificity is a strength: it makes your marketing concrete, your product decisions clear, and your word-of-mouth easy, because a satisfied customer can explain exactly who you are for. For a builder especially, a narrow niche is where the building advantage concentrates, because you can build something that fits one audience perfectly rather than something generic that fits no one well.

But there is a floor below which niching down stops helping and starts strangling, which is when the niche becomes so narrow that there are not enough customers in it to sustain a business. The art is to niche down to the point of clarity and reachability without niching down to the point of having no market, and the way to find that line is the same as everything else here: test. If a narrow niche shows real demand, you have found focus; if it shows none because it is simply too small, you widen until there are enough people with the problem. Niche down for sharpness, but keep checking that there is still a real market underneath you, because precision aimed at an empty room is not a business.

A few signals suggest a niche is worth committing your building skill to. The clearest is that people you talk to lean in rather than nod politely — they recognize the problem immediately, have tried to solve it, and want to know when they can have your solution. Another is that you understand the problem well enough to anticipate objections and edge cases before customers raise them, which means you are building from real knowledge rather than a guess. A third is that you can actually reach the people who have the problem through effort rather than budget, and a fourth is that serving them does not require a cost structure that would sink a lean operation. When several of these line up, you are probably looking at a good niche.

Conversely, the warning signs are worth naming: enthusiasm that comes only from you, a problem you find technically exciting but cannot point to anyone actually suffering, a market you cannot figure out how to reach, or economics that require a big standing cost before the first sale. Any of these should slow you down, because they are exactly the conditions under which a builder's skill produces an impressive solution to a non-problem. Choosing a niche well is less about a flash of insight and more about an accumulation of honest signals pointing the same way — real demand, real understanding, real reachability, and viable economics. When those align, commit; when they do not, keep testing, because the building skill is too valuable to spend on a niche that the signals are quietly telling you is wrong.

One luxury that being a builder affords is not having to get the niche right on the first guess. Because you can build cheaply, you can run several small bets and let the market tell you which niche is worth committing to, rather than betting everything on a single choice up front. A portfolio of small, low-cost experiments is a way of asking several niches the same question — does anyone here actually want this — and listening to which one answers loudest. The builder who treats niche selection as a series of cheap experiments will usually find a better niche than the one who agonizes over picking the perfect one in advance.

This reframes the whole decision from a high-stakes bet into an iterative search, which fits how good niches are usually found in practice: not by brilliant foresight but by trying things, paying attention, and doubling down on what works. The portfolio approach only works if each experiment is genuinely cheap — which loops back to the cost-structure filter — but when it is, the ability to build becomes the ability to search the space of niches efficiently. Let the experiments reveal the niche, commit your real effort to the one that shows a true signal, and treat the rest as the cost of finding it. For a builder, the smartest niche strategy is often to stop trying to pick perfectly and start trying things cheaply.