I wrote my first line of production code twenty-five years ago. For most of those years I built other people’s software — enterprise systems, agency work, the occasional doomed startup. I was good at it and quietly unhappy, and it took me an embarrassingly long time to understand why.
The trap of being the reliable one
When you’re the dependable senior engineer, the work flows toward you. More systems, more meetings, more responsibility for things you didn’t design and can’t change. I mistook that gravity for success. It was just accumulation — and none of it was mine.
The skills compounded. The ownership didn’t. I could architect a system that would outlive me and still have nothing at the end of the year with my name on it.
What finally changed
Two things, close together. First, the tools got good enough that one person could credibly ship a real product — infra, payments, distribution, the whole stack — without a team. Second, I stopped treating “indie” as a lesser version of “real” software work.
That second shift was the harder one. Twenty-five years of enterprise habits told me that small meant unserious. It doesn’t. Small means I can hold the whole thing in my head, change my mind on a Tuesday, and answer to the user instead of a roadmap committee.
Where that leaves me
Now I build small, anti-fragile tools in the open, on my own terms. Some ship, some don’t. The difference is that the wins are mine and so are the mistakes — and that turns out to be the part I was missing the entire time.
If you’re the reliable one, quietly unhappy, twenty years into building someone else’s thing: the tools are ready now. The only question left is whether you’ll let yourself build something that’s yours.