The hardest part of indie hacking is not coading, it's knowing when to kill a feature.
by•
curious how others handle this.
when you are building solo or in a tiny team, every feature feels like your baby. you spend days tweaking an edge case or adding a cool little toggle beacuse you think it's neat.
then you launch, and crickets. nobody touches it.
lately, i have been trying to force myself to look at user data and ask- am i building this because it actually solves a problem or just because i enjoyed coding it?
it's brutal to throw away code you spent an entire weekend writing, but keeping clutter worse.
how do you guys draw the line between a genuinely necessary feature and just shiny object syndrome distractions? would love to hear how others ruthlessly prioritize.
33 views
Replies
Code is cheap; cognitive load for your users on the other hand is not. If a feature does not directly drive retention or fix a repeated user complaint, cut it.
@amanndaphillips spot on. the "code is cheap" part hits hard. it's so easy to keep building just because we can, foretting the actual mental friction it adds for the user.
I killed tasks in Focushours, my weekly focus tracker website. A weekly hours tracker with a task list stops being a tracker and becomes a worse to-do app. Removing it made the product easier to explain in one line, which turned out to matter more than the feature.
@ghaisdahdouh man, that is such a great example. turning a tracker into a "worse to-do app" is a trap so many of us fall into. simplifying the one liner makes all the difference.
The line I use: a feature stays if it shows up in one of two places, the numbers or the support inbox. If nobody taps it and nobody writes about it, it goes, however neat the toggle was. Two habits make the cut less brutal. The first is a written list of things I looked at and did not build, with the date and the reason, so a shiny idea does not come back every month wearing a new hat; when it comes back I read why I said no and ask whether the reason changed. The second: I started my current app from a previous project's architecture and deliberately left half its features behind, the whole photo and video side, instead of porting them just because they were already written. Code that exists is the most seductive kind of clutter, because keeping it feels free. It is not free. Every extra screen is one more thing a new user has to get past before they find the one thing the app is for.
@gbasovv the "list of things i looked at and did not build" is such a brilliant habit. stealing that. and you are so right about existing code being seductive clutter, it feels like a waste to leave it, but keeping it always costs more in the long run.
@gazi_nurul_hasan One detail that makes the list work: it is not a separate ideas file. Each entry sits in the notes of the area it belongs to, so "yearly plan billed monthly, looked at, not built" is written next to the pricing notes, with the date and the reason. Two effects. I reread it whenever I touch that area, not when I happen to remember the list exists. And the coding agent reads those notes before changing anything there, so it stops pitching the same idea back to me every other week.