Software that does one thing
Single-purpose software is easier to finish, easier to trust and easier to replace. It also has real costs, and a suite is sometimes the right answer. Here is how we think about the trade-off.
Our apps are narrow on purpose. A batch renamer renames. An archive utility packs and unpacks. A keyboard-sound app plays keyboard sounds. None of them has a feed, a dashboard, a team plan or an assistant.
This is a deliberate choice, and it is worth explaining both why we make it and where it is the wrong one.
An old idea
"Make each program do one thing well" is usually traced to Doug McIlroy's summary of the Unix philosophy in the late 1970s. The idea was that small programs, each doing one job properly, could be combined to do bigger ones — and that a program trying to do many things would do most of them badly.
Desktop software drifted the other way. Word processors gained drawing tools, email clients gained calendars, and then everything gained a chat feature. There are commercial reasons for that drift, and some of them are good for users. But the original argument still holds for a certain kind of tool.
What narrowness buys
It can be finished. A tool with a defined job can reach a point where it does that job completely. After that, the work is maintenance: keeping up with new versions of macOS, fixing bugs, improving what is there. A product that must keep adding features to justify itself is never finished, and neither is its list of bugs.
It is easier to trust. An app that only renames files has no reason to access the network, your contacts or your camera. When the job is narrow, the permissions it needs are narrow too, and anything beyond that is visible and suspicious. A suite that does forty things legitimately needs forty kinds of access.
It is easier to learn and to remember. You open it, it does the thing, you close it. Six months later you still know how.
It is easier to replace. If a better renamer appears, you switch renamers. Nothing else in your workflow is tied to it. With a suite, switching one function means switching all of them, which is exactly why suites are hard to leave.
It fits a small team. We are a small company that sells software once rather than by subscription. A narrow tool is something a small team can build properly and maintain for years. A sprawling one would be done badly.
What narrowness costs
It would be dishonest to present this as free.
More apps. Five small tools mean five things to install, update and learn, and five icons competing for space. For someone who wants one app that handles "all my files", that is worse.
Gaps at the joins. When one tool finishes and another starts, you are the glue. Moving a file from a renamer to an archiver is a drag and drop — fine — but a truly integrated workflow would avoid it.
Inconsistency. Different small tools from different developers look and behave differently. A suite from one vendor is at least consistent with itself.
Missing adjacent features. Sometimes you want the tool to do one more thing, and the answer is "no, that belongs elsewhere". That is frustrating in the moment even when it is right.
When a suite is the right answer
If a set of jobs genuinely share data and happen together constantly — writing, citing and formatting a long document, or a team's tasks, files and conversations — an integrated tool can remove real friction. The integration is the product.
The test we use: do the jobs share state, or merely happen near each other? Captions and the video timeline share state — the caption must know where the speech is — so both belong in the video editor. Renaming files and archiving them merely happen near each other, so they are separate apps.
How narrow tools cooperate
The answer to the joins is not a bigger app. It is standard ground between small ones:
- Ordinary files in ordinary formats — a folder that one tool renames and another archives, with no import or export step.
- The system's own data — contacts in the macOS Contacts database rather than a private copy, so any app you choose can read the same records.
- Shortcuts, Finder Services and command-line tools, which let a small tool be one step in a larger sequence without either tool knowing about the other.
What this means for our apps
Each one has a job it tries to do completely, and a list of things it deliberately does not do. Garfi has one picture-in-picture layer, not a compositing engine. Ziploom creates ZIP and 7Z, not RAR. ClackSmith plays sounds and cannot tell which key you pressed. Those limits are written on the product pages, not discovered after purchase.
When we make something new, it tends to be a new app rather than a feature in an existing one. That is not always the most convenient answer, but it is the one that keeps each tool small enough to be good.