Are We Building Too Many Features Nobody Asked For?

This is great work — what's the biggest thing you'd do differently if you started over?

I’ve shipped my share of “we should totally add this” features, and the biggest lesson is that requests don’t automatically mean demand.

I use analytics to spot where users struggle, support conversations to understand why, and requests to check how common the pain is. Then I prioritize by impact, confidence, and effort, with a clear success metric before building.

If there’s uncertainty, I test with a small beta, prototype, or manual workflow first. Competitor features are clues to investigate, but the deciding factor is whether solving that problem improves a measurable outcome for our users and business.

This hits right where it hurts for most indie hackers. We’ve all been guilty of building a feature because it was "cool to code" rather than "needed by the market."To answer your question, my framework for what to build next shifted completely after wasting 3 weeks on an advanced analytics dashboard that exactly zero users clicked on.Here is how I filter everything now:The "Pay Before Built" Rule: If a customer requests a massive feature, I ask: "If I build this by next Tuesday, would you be willing to upgrade to the $X tier today to support it?" If they hesitate, it’s a nice-to-have, not a pain point.Support Messages > User Interviews: I’ve found that user interviews can sometimes mislead you because people want to be nice and will say "Oh yeah, that feature sounds cool!" Support messages, however, are raw data. If multiple users are complaining about a friction point or asking how to do something, that is your next feature.The 3-User Rule: Unless 3 entirely unrelated paying users explicitly ask for the same thing, it goes into the icebox. No exceptions.The biggest mistake I made: I used to look too much at competitor research. I thought, "Well, competitors have this integrations page, so I need it too." Turns out, half of the features your competitors have are also dead weight that they built out of intuition and are too scared to remove. Copying competitors means copying their mistakes.Focus on LaunchNest's core value proposition and ignore the noise. If the product is slightly buggy but people are still using it because it solves a painful problem, you're on the right track.

I try to separate evidence from enthusiasm: keep a short list of requested problems, then rank each feature by how often the problem appears, how painful it is, and whether it supports the core workflow. Before building, I test the smallest version manually with a few users. If nobody changes behavior or asks for it again, that is usually the signal to stop.