When a Desktop App Beats a Subscription

There is a quiet tax on small businesses that nobody itemises.

It is the slow accumulation of subscriptions that exist to make small repeated tasks slightly less painful. A note tool. A snippets tool. A clipboard tool. A small dashboard for a thing that should not need a dashboard. A team plan because one person needs the export feature and the rest got dragged along.

Each one is reasonable on its own. The pattern, taken together, is less reasonable.

Some of those subscriptions are genuinely the right answer. They handle real shared work, real customer data, real collaboration. They earn their place. But a surprising number of repeated workflows do not need a platform at all. They need one focused local tool that removes a small bit of work and then stays out of the way.

That is the case for the tiny desktop app.

Some work is better kept on your computer

A workflow tends to suit a desktop app when it touches things a SaaS product struggles with by design.

Things like:

• files that live on your machine, not in someone else's bucket
• private data that should not be uploaded to a third party at all
• short repeated actions that need to happen in under a second
• background work that has to keep running while you are doing something else
• access to your local development environment, your local notes, your local clipboard, or the bits of macOS itself
• a small focused job, used many times a day, by one person

A web app can do most of this eventually. It just usually adds a login screen, a sync model, a new permissions surface, a billing relationship, and a noticeable lag between you pressing the key and something happening.

If the underlying job is "the same five-second action, all day, on local material", every layer of cloud infrastructure between you and the action is a tax. Sometimes the right answer is a small Mac app that opens in fifty milliseconds, does its job, and goes back to being out of the way.

Subscription software still suits shared work

It is worth being clear about where this argument does not apply, because the alternative is the kind of thinking that gets a small business stuck running its accounts in spreadsheets.

A subscription is usually the right answer when several people need to edit the same thing at the same time, when the data is the source of truth for invoicing, payroll, support, or anything regulated, when the workflow has to integrate with several other systems your team already uses, or when the value mostly comes from a shared history that has to survive whoever is on holiday this week.

Accounting, payments, customer support, shared content, project management for a team, helpdesks: these are subscriptions for good reasons. The shared layer is the product.

The trap is using the same instinct for everything. Not every small piece of work needs a shared layer. Some of it just needs to happen quickly.

Three jobs that suit a desktop app

We run nine Mac apps across the studio, all built in-house, because tiny tools often beat giant platforms for the work that sits between meetings.

Some of them are deliberately unglamorous.

Drift is a small .env manager for projects with several environments. It exists because nothing breaks a deploy quite like a missing key, and a focused local tool can show the difference between two environments faster than any web dashboard.

Amber takes git-like snapshots of local development databases, so a developer can experiment with a destructive change and roll back in seconds rather than reseeding from scratch. That work is intrinsically local. A cloud product cannot help here without uploading the database, and the database is the point.

Grove is a git worktree manager. It does one thing: makes it less painful to have several active branches in their own folders. There is no AI in Grove, no sync, no account, no shared workspace. It is a structural tool that saves a fiddly bit of admin every day.

Waypoint is a Markdown notes app for active development work. The notes live on the developer's machine because that is where the work is. It does not try to replace the team's shared knowledge base. It exists to keep context attached to the worktree it belongs to.

Fuse sits in the menu bar and helps a reviewer get through a queue of pull requests without switching into another browser tab. It calls AI tools to help score risk and draft review comments, but it does so locally, scoped to the project the developer already has open.

None of these are flashy. None of them would survive as standalone SaaS products, because none of them are the kind of work people pay £15 a month for.

That is the point.

They are the kind of work people would otherwise just keep doing slowly.

Desktop apps need ongoing maintenance

A desktop app is not the right answer for most products.

If three people need to look at the same record at the same time, you want a web app. If the work has to be available on a phone, you want a web app or a real mobile app. If the value depends on a shared history across the whole team, you want a web app. If the customer is the user and you cannot ask them to install anything, you want a web app.

A focused desktop app also has its own quiet costs. It needs to be installed, signed, kept up to date, and supported on the platform it runs on. We ship Mac builds because that is what our team uses, and Windows or Linux versions are a real piece of work, not a checkbox.

The point is not that subscriptions are bad and apps are virtuous. The choice between them is a real design decision, and it usually goes to whichever one is currently in fashion. The currently fashionable answer is "make it a SaaS". That is not always the right one.

Choose the smallest tool that fits

Before adding another subscription to the list, it is worth asking four questions about the workflow it would replace.

The first is whether the work is shared or solitary. Genuinely shared work usually wants a web app. Solitary work, repeated many times a day, often wants a small local tool.

The second is whether the data should leave the machine. Source code, dev databases, drafts, private notes, client material under embargo, anything that touches authentication: keeping that local is often a security feature, not a limitation.

The third is whether the speed of the action matters. If the answer is "no, an extra second is fine", a web app is usually fine. If the answer is "I do this thirty times an hour", a small native tool will give you the time back.

The fourth is whether the underlying job is interesting enough to deserve a platform. Many do not. They deserve a sharp little tool that does one thing well and asks for nothing else.

If the answers all point one way, the desktop app probably wins.

If they point the other way, pay the subscription with a clear conscience.

A focused app can replace several subscriptions

The interesting use of AI in our own work has been small local tools that take a repeated job and make it half as long. AI built into the work, not into a separate window the team has to switch into.

Sometimes that means an AI feature inside the tool, like Fuse drafting a review comment for confirmation, or Sentinel grouping a noisy error log into something a person can act on. More often it means a tool that does not advertise AI at all and just makes the work feel less heavy.

That is the test we use before suggesting a desktop app to anyone else. If a small tool living next to the work would save a real person a real piece of effort every day, it is probably worth building. If the only reason it exists is to look impressive in a demo, the team will be back on a subscription within a quarter.

The cloud has won most arguments it deserved to win. This one is still open.