Shipping From Curiosity, Not Fear
Shashank Manjunath
A lot of indie-hacker advice is, once you notice the pattern, fear management wearing the language of strategy. Ship fast because someone else will beat you to it. Validate before you build because you might waste your time. Charge from day one because free users will never convert and you'll have wasted months on nothing. None of this advice is technically wrong. All of it is organised around avoiding a bad outcome rather than pursuing an interesting one, and it's entirely possible to build that way for eighteen months straight without noticing how much it costs.
What fear-driven building actually looks like
The clearest specimen is a feature almost every small habit-tracking product ships some version of about a year in: a social-comparison leaderboard for streaks, built because "engagement loops" are supposedly the difference between apps that grow and apps that stall, and stalling is frightening. The builder doesn't want it. Nobody has asked for it in any depth. It gets built anyway, in about a week, because the fear of being the founder who didn't try the obvious growth lever feels worse than the cost of building something with no real conviction behind it.
It performs exactly as well as work built from that place usually performs: fine, forgettable, a small bump in one metric and no lasting effect on anything that matters. It gets maintained for a year before being quietly sunset, and in all that time it never once makes anyone curious about anything. It's a chore taken on to manage an anxiety that, on reflection, was never really about the leaderboard at all.
"A week into building it, the builder already knows they don't care about the answer to any question the leaderboard might raise. It gets built anyway, because not building it feels like admitting fear."
The feature that comes from the other place
Contrast that with a clean-streak note field in a quit-tracking app — the small text box where users jot down what triggered a slip. It exists because the builder was genuinely curious what people would actually write there, not because any growth framework said notes fields drive retention. There is no strategic case for it at all; if anything, a strategic case against it, since a free-text field is exactly the kind of low-leverage feature the fear-driven playbook says to skip in favour of something more "core."
Reading those notes, once real users start filling them in, turns out to be the single most useful research on the entire product. The patterns in what people write — the specific times of day, the specific emotional states, the specific situations that precede a slip — shape almost everything that comes after, including, eventually, a redesigned streak mechanic that becomes the product's actual core loop. None of that comes from a validated hypothesis. It comes from being curious enough about a small, unstrategic feature to actually read what it produces.
A pattern, once you start looking for it
Name this distinction and then run the honest audit: go back through eighteen months of commit history and the shipped-feature list, and sort everything into one bucket or the other. It won't be a clean split — some features genuinely start in one place and drift into the other mid-build — but the rough sort is still instructive. On one small product that ran exactly this exercise, about a third of what shipped in that period was recognisably fear-driven: built to head off a specific bad outcome, churn, being out-featured by a competitor, looking unserious to the small audience watching the build in public. Almost none of that third is still in the product today. Most of it got quietly removed within a year, usually without a single user noticing or complaining, which is itself a fairly damning signal about how load-bearing it ever really was.
The curiosity-driven work told a completely different story. It wasn't a larger share of the total output — if anything, slightly smaller, because curiosity doesn't arrive to order the way a roadmap deadline does. But nearly all of it survived, and several pieces of it — the notes field chief among them — turned out to be structurally important to decisions made much later, in ways nobody could have predicted at the time. Curiosity-driven work doesn't feel more productive in the week it ships. It just tends to still be there, quietly earning its keep, eighteen months later, when you go looking.
"A third of what got built out of fear was gone within a year. Almost everything built out of curiosity is still there. That ratio is the only roadmap discipline worth trusting."
Why this is hard to sustain, and what makes it easier
Curiosity-driven building isn't automatically better in some tidy, universal sense — there are absolutely moments where the fear-driven instinct is correctly pointing at a real risk, and ignoring it would be its own kind of self-indulgence. The narrower, more useful claim is this: fear-driven work reliably produces competent, forgettable output, and curiosity-driven work reliably produces either something genuinely useful or a fast, cheap, honest failure you actually learn from. Fear rarely fails fast, because fear is trying to avoid the appearance of failure more than the fact of it, so it produces mediocre, defensible, hard-to-kill work instead.
The habit that makes this sustainable is small and almost embarrassingly simple: before building anything, write one sentence answering "what do I genuinely want to know the answer to here" — not "what problem am I solving" or "what metric will this move," just the curiosity itself. If the honest sentence won't come, don't build it yet, no matter how defensible the strategic case looks on paper. That filter kills off a lot of ideas that would have made a perfectly reasonable roadmap slide and taught nobody anything. It's also the only filter that reliably points at the small, weird, unstrategic features — like a notes field nobody asked for — that end up mattering more than anything a growth framework would have recommended instead.
"If you can't say what you're curious about, don't build it yet. That one sentence kills more bad ideas than any strategic framework."
The leaderboard code, in this story, stays in a private branch — half a joke, half a genuine reminder. Every few months it gets opened, skimmed, and put to the same honest question: would this be worth building again today? The answer is always no, and the fact that it's always no is the point — a small, cheap way of checking whether the fear that produced it has actually left the building, or just gone quiet for a while. Building small enough to afford that kind of self-audit, on a single afternoon, with no committee to convince either way, is most of what makes building alone worth the parts of it that are genuinely harder.
Shashank Manjunath
Small & Deliberate · Editor & sole writer
An Indian builder-operator writing about AI, teams, and the cross-cultural patterns shaping tech — read from Asia outward, with the West as the contrast class. This is a one-person publication; reply to any email and it reaches me directly.