We all talk about shipping fast. Launch early, iterate weekly, keep momentum alive.
But here’s the catch: not every week should look like a feature buffet.
This past sprint I felt the itch: “Shouldn’t I add something new? Maybe a shiny dashboard, a feed, a leaderboard, or another automation?”
Instead, after coming several feature proposals for Indie10k, I resisted. I fixed bugs, tightened UI flow, cleaned up small annoyances.
Reliability itself is a feature.
A stable product builds trust.
A consistent product builds habit.
A boring product (in a good way) builds revenue.
15 years of work experience in big tech has made me think of progress as OKRs, KPIs, quarterly plannings, monthly feature check-ins, etc.
I thought progress = new features.
But, in indie world, progress = any action you have taken, including rejecting new feature additions. It can be as little as removing friction , or maybe just having a chat with a user about their actual pain.
What do you think—does not shipping sometimes help you ship faster in the long run?
Totally agree with this. We spent 10 weeks refining core stability before layering on anything new. And honestly, that’s what made the later releases stick. Shipping “nothing” often feels stale in the moments, but it definitely gives velocity, trust, and adoption later on!
The fundamentals of your project are far more important than an excessive number of features.