What we look at before we build anything
The last of this series of notes, and the question behind all the others — how we decide whether something is worth making. Six tests an idea has to pass, and what they rule out.
This is the hundredth of these notes, and a good place to explain the question that sits behind all of the others: how do we decide that something is worth building?
We are a small company. Every product we make is one we will have to maintain for years, through new versions of macOS and iOS, new hardware and new expectations. That makes the decision to start expensive, and we try to make it carefully.
These are the tests an idea has to pass.
1. Is there a real, recurring job?
Not a feature, not a trend — a job that people do repeatedly and find tedious, slow or risky. Renaming hundreds of files. Opening an archive in the wrong format. Tidying an address book that has outgrown the standard card. Turning clips into a video before the evening is over.
The best sign is that we do the job ourselves and are annoyed by it. The second best is that people describe the same annoyance, in their own words, without being prompted.
If the job happens once a year, it does not need an app. If it happens every week, it might.
2. Is the existing answer failing in a specific way?
Most jobs already have tools. A new one is worth building only if the existing ones fail in a way we can name:
- they upload data that has no reason to leave your device,
- they ask for permissions far beyond what the job requires,
- they charge rent for something that runs entirely on your own machine,
- they are so broad that the one job you need is buried,
- or they are abandoned, or were never native to the platform.
"The existing tools are fine, but ours would be nicer" is not enough. We would be spending years to make something marginally different.
3. Can it be done on the device?
Almost everything we make does its work locally, and we check early whether an idea can. If it needs a server — to store data, to process it, to sync it — the product changes shape entirely: it needs accounts, security for stored data, ongoing hosting costs and, eventually, a subscription to pay for them.
Sometimes that is right. AI on Radar is a news service, and news needs a server. But for tools that act on your files, contacts and images, the answer is almost always that the device is enough, and then it is where the work should happen.
4. Can it be finished?
We look for a job with edges. A renamer has a clear scope; "a better file manager" does not. A narrow tool can reach a state where it does its job completely, after which the work is maintenance and refinement rather than an endless list of features.
A product that can never be finished can never be sold once. Our one-time pricing depends on this test.
5. What are its honest limits?
Before building, we try to write down what the product will not do, and whether it is still worth making with those limits stated plainly on its page.
- ClackSmith cannot play a different sound for each key, because it never learns which key was pressed. We decided the privacy was worth that limit.
- Ziploom cannot create RAR files, and runs on Apple silicon Macs only.
- Garfi supports one picture-in-picture layer.
- Miyu Paint's free export stops at 2048 pixels.
If a product only makes sense when its limits are hidden, we do not build it.
6. Does it fit the platform?
We build native apps for Apple platforms and try to use the system rather than work around it: the Contacts database rather than a private copy, Finder and the file system rather than a proprietary library, Apple's speech recognition rather than an external service, the App Store for purchases rather than our own licence servers.
An idea that fights the platform — needing permissions the system discourages, or duplicating what the system already does — usually produces a worse product and a fragile one.
What these tests rule out
A lot. Ideas that need our servers to hold your data. Ideas that only work with an account. Features added to an existing app because they would be easy to sell, when they belong somewhere else. Products for trends that will not last as long as the maintenance commitment. Anything we could only describe honestly by admitting it is not much better than what exists.
It also means we say "coming soon" without details until something is ready, and publish limits alongside features.
After the hundredth note
These notes were written to answer questions people actually search for, with the manual way first and our tools only where they genuinely help. The same six tests decided which of those tools exist at all.
If there is a job you do every week that the existing tools handle badly, we would like to hear about it through the contact page. It is exactly how the next idea starts.