Building things that don't need to be built
Every engineer I know has a graveyard of side projects. Mine has a particular flavor: tools that solved problems I didn’t have, built with architectures that couldn’t justify their own complexity.
I used to think this was harmless. Building things is how we learn, after all. But somewhere along the way, I noticed a pattern — the projects I was most proud of were rarely the ones I enjoyed building the most. The ones I enjoyed most were the ones where I stopped building sooner.
The curiosity trap
Curiosity feels productive. When you hit an interesting problem, exploring it feels like the right move. And often it is. The trap is that curiosity doesn’t have a natural stopping point. There’s always another abstraction to try, another optimization, another rewrite of the config system that nobody will ever see.
The question I’ve learned to ask is embarrassingly simple: who is this for?
If the answer is “me, to learn” — great, but then set a boundary. One weekend, not one quarter. If the answer is “nobody, it just seemed cool” — that’s fine too, but be honest about it. The danger isn’t building useless things. The danger is calling them something they’re not, and letting them eat the time you needed for the things that matter.
The maintenance tax
Here’s what nobody puts in the readme: every project you keep alive is a subscription you pay for with attention.
A tool with three users is a promise. A library with an open issue tracker is a promise. Even a private script that your teammate relies on is a promise. Promises compound quietly, and then all at once you look up and you’re spending your Saturdays on software that was supposed to be fun.
I’ve started treating “don’t build it” as a legitimate engineering decision — one that deserves the same rigor as any architecture choice. Sometimes the most senior thing you can do is close the editor.
Knowing when to stop
These days I use a simple heuristic. Before I add anything to a project — a feature, a dependency, a refactor — I ask:
- Does this make the thing more useful or just more impressive?
- Will I still want to maintain this in six months?
- Am I building this because the project needs it, or because I want to avoid the boring work of finishing it?
If I can’t answer all three comfortably, the answer is no. Not “later” — no.
The best projects I’ve shipped recently are also the smallest. Not because small is virtuous, but because stopping is a skill, and like any skill it gets easier with practice.