Shipping From Curiosity, Not Fear

A lot of the indie-hacker advice I read in my first year of building Frictionwell was, once I noticed 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 I spent about eighteen months building that way before I noticed how much it was costing me.

What fear-driven building actually looked like

The clearest evidence, in hindsight, is a feature I built about a year in: a social-comparison leaderboard for streaks, shipped because I'd read that "engagement loops" were the difference between apps that grew and apps that stalled, and I was afraid of stalling. I didn't want it. Nobody had asked for it in any depth. I built it anyway, in about a week, because the fear of being the founder who didn't try the obvious growth lever felt worse than the cost of building something I had no real conviction in.

It performed 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 mattered. I maintained it for a year before quietly sunsetting it, and the whole time I maintained it, it never once made me curious about anything. It was just a chore I'd taken on to manage an anxiety that, on reflection, wasn't really about the leaderboard at all.

"I could tell, a week into building it, that I didn't care about the answer to any question the leaderboard might raise. I built it anyway, because not building it felt like admitting I was scared."

The feature that came from the other place

Contrast that with Quit Log's clean-streak note field — the small text box where users could jot down what triggered a slip. I built it because I was genuinely curious what people would actually write there, not because any growth framework told me notes fields drove retention. There was 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 tells you to skip in favour of something more "core."

Reading those notes, once real users started filling them in, turned out to be the single most useful research I did on that entire product. The patterns in what people wrote — the specific times of day, the specific emotional states, the specific situations that preceded a slip — shaped almost everything that came after, including, eventually, the redesigned streak mechanic that became Frictionwell's actual core loop. None of that came from a validated hypothesis. It came from being curious enough about a small, unstrategic feature to actually read what it produced.

A pattern once I started looking for it

Once I named this distinction for myself, I went back through eighteen months of my own commit history and shipped-feature list and tried to sort everything I'd built into one bucket or the other, as honestly as I could manage. It wasn't a clean split — some features genuinely started in one place and drifted into the other as I worked on them — but the rough sort was still instructive. About a third of what I'd shipped in that period was recognisably fear-driven: built because I was afraid of 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 my 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 I made much later, in ways I couldn't have predicted when I built them. Curiosity-driven work doesn't feel more productive in the week you ship it. It just tends to still be there, quietly earning its keep, eighteen months later, when you go looking.

"A third of what I built out of fear is gone within a year. Almost everything I built out of curiosity is still here. That ratio is the only roadmap discipline I actually trust anymore."

Why this is hard to sustain, and what makes it easier

I don't think curiosity-driven building is 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. What I've come to believe, after watching both modes produce work inside the same small company, is narrower and more useful than "always follow curiosity": 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's actually made this sustainable for me is small and almost embarrassingly simple: before I start building anything now, I 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 what I'm curious about. If I can't write an honest sentence, I don't build it yet, no matter how defensible the strategic case looks on paper. It has killed off a lot of ideas that would have made a perfectly reasonable roadmap slide and taught me nothing. It's also the only filter I've found that reliably points me 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 told me to build instead.

"If I can't say what I'm curious about, I don't build it. That one sentence has killed more bad ideas than every strategic framework I've ever tried to apply to this business."

I still keep the leaderboard code in a private branch, half as a joke and half as a genuine reminder. Every few months I open it, skim the diff, and ask myself honestly whether I'd build it again today. The answer is always no, and the fact that it's always no is the point — it's 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 this kind of self-audit, on a single afternoon, with no committee to convince either way, is most of why I still think building alone is worth the parts of it that are genuinely harder.