On Building Small Things
Why I keep coming back to small, focused tools — and what I've learned from shipping them.
The projects I'm most proud of are usually the small ones.
Not the ambitious rewrites or the grand systems — the little utilities, the scripts that solve exactly one problem, the apps that do one thing well and don't apologize for it.
Small scope, sharp focus
A small project forces a decision: what does this actually do? You can't hide behind features. The thing either works or it doesn't, and everyone can see it.
There's something clarifying about that constraint. When you can only have one feature, you make sure it's the right one.
The discipline of stopping
The hardest part of a small project isn't building it — it's resisting the urge to expand it. Every useful tool attracts feature requests, half from users, half from yourself.
Good small things stay small. They know what they are.
Shipping changes you
There's no substitute for the experience of putting something out into the world. It teaches you things no tutorial can: how to handle feedback, how to prioritize, how to let go.
Build small. Ship often. Learn constantly.