Case Studies Why I build small, focused tools
Why I build small, focused tools
TL;DR The thread across everything I ship, WordPress plugins, browser extensions, GitHub Actions, is that each does one thing well and refuses to grow into a suite. Small, focused tools are easier to trust, review, maintain, and keep fast, and a collection of them beats one product that does everything adequately.
If you line up everything I have shipped, fourteen WordPress plugins, seven browser extensions, a couple of GitHub Actions, a pattern is obvious: each one does a single thing, and none of them tries to do everything. That is not an accident. It is the core of how I think about building software.
The principle
A tool should do one thing well and refuse to become a suite. Every plugin trims one kind of bloat, or moves one kind of content, or fixes one metric. Every extension exposes one browser capability. Every Action guards one part of a release. When a new idea does not belong to a tool's single job, it becomes a separate tool, not a feature bolted onto an existing one.
This is an old idea, small sharp tools that compose, and it holds up because the benefits are real and compounding.
Why small wins
A focused tool is better on almost every axis that matters.
- Easier to trust. A user can tell in a minute what it does and decide if they want it. A sprawling suite is a leap of faith.
- Easier to review and maintain. Less surface, fewer paths, fewer ways to break. WordPress.org review goes smoother, and so does every future change.
- Faster. A tool that does one thing is not carrying the weight of nine features you never use.
- Composable. People take exactly the pieces they need instead of adopting a platform to get one capability.
The cost of the suite
The opposite path is seductive and usually wrong. A focused tool grows "just one more" feature, then another, until it does many things adequately and nothing cleanly. It gets slower, harder to review, and less pleasant to use. The suite is often less a product decision than a failure to say no.
Resisting that is the actual discipline. It is easy to add; it is hard to keep something small on purpose.
What it adds up to
A collection of small, focused tools is a better body of work than one product that tries to do it all. Each piece is trustworthy, fast, and maintainable, and together they cover a lot of ground without any single one becoming a mess. That is why I build the way I do, and why the same instinct shows up whether I am writing a plugin, an extension, or an Action.
The full body of work is in the products and Chrome extensions sections of the site.
FAQ
Why build many small tools instead of one big product?
Because a focused tool is easier to understand, trust, review, and maintain, and it stays fast because it is not carrying features you do not use. A collection of small, sharp tools lets people take exactly what they need, where one big suite forces the whole thing on them.
Isn't a suite more convenient for users?
Sometimes, but convenience often hides bloat: a suite tends to do many things adequately and few things cleanly, and you carry all of it to use any of it. A focused tool does its one job well and gets out of the way, which is its own kind of convenience.
How do you resist feature creep?
By treating a new idea as a candidate for its own tool rather than an addition to an existing one. If it does not belong to the tool's single job, it becomes a separate, focused thing. Saying no to scope is the discipline that keeps each tool worth using.