The case for tiny, single-purpose Mac apps

Open the Applications folder of any longtime Mac user and you will find a strange pattern. There are five or six big-name apps that they actually open every day, and another forty small utilities that quietly run in the menu bar, on a hotkey, or as a Quick Action. The big apps get redesigned every two years, sometimes painfully. The small utilities just keep working.

This post is about why the small utilities win, and what it would look like to build software with that pattern in mind on purpose.

The pattern

A “tiny app” in this context is something with one job, a simple UI surface (often menu bar, sometimes a window), and a feature list that fits on one screen. Examples almost any Mac power user will recognize:

Itsycal, a tiny calendar that lives in the menu bar.
Hand Mirror, which turns your camera into a one-click mirror.
Maccy, a clipboard history.
Rectangle, a window manager.
Pure Paste, which strips formatting from anything you copy.
Lungo, which keeps your Mac awake on demand.

None of these are trying to be platforms. None have a “Pro tier” with feature gates. None ask you to create an account. Most are free or one-time purchase. Some are open source. They all do exactly one thing, and they have done that one thing for years without their developers ever feeling the need to add a kanban board.

Why this works at the small end and breaks at the big end

The reason tiny apps survive is that the per-feature complexity tax never accumulates. A clipboard manager that only manages clipboards has a small surface area. The bug surface is small. The settings page is small. The release notes are small. The developer can hold the entire app in their head, which means they can fix problems quickly and ship updates without breaking other features.

The moment a tiny app tries to grow into a “platform,” the math changes. Every new feature multiplies the testing matrix. Every new setting adds an edge case. Every new integration brings someone else’s bugs into your codebase. The complexity tax is roughly quadratic.

Big apps survive this only by hiring teams. Tiny apps survive by refusing to grow.

The economics

A tiny app at $5 to $15 paid once can be built and supported by one person with a thousand monthly downloads. The math works because the marginal cost of an additional user is essentially zero. There is no server. There is no support team beyond the developer. There is no analytics dashboard with a monthly bill.

The same developer trying to support a “platform” at the same price point would go broke. Platforms need teams. Teams need salaries. Salaries need recurring revenue. That is why every “small app that became a platform” eventually moves to subscription. The economics force it.

The interesting consequence is that the tiny-app developer has stronger incentives to keep their app focused than the platform developer does. Adding a feature is a real cost to the tiny-app developer. They will resist it. The platform developer has a quarterly OKR that requires shipping new features, so they will add it whether it is needed or not.

The design discipline

The hardest part of building a tiny app is saying no to features. This is not the kind of “no” that comes naturally to engineers, who tend to see every feature request as a small interesting problem worth solving. It is the kind of “no” that comes from a strong opinion about what the app is.

The right test is not “would this be useful to some user.” The answer is always yes for any feature. The right test is “would this make the app worse for the users who already love it.” A clipboard manager that adds notes is no longer a clipboard manager. A todo app that adds projects and areas and tags is no longer a tiny todo app. The user who loved the focused version starts noticing the weight.

Most successful tiny apps have a public “anti-roadmap” of features they will never add. Sometimes this is explicit on the website. More often it is implicit in the unchanging release notes. Five years and the app still does the one thing. That is the feature.

The menu bar is the perfect surface for an app that does one thing because it is always available, takes up almost no visual real estate, and has a single click affordance that opens a popover. There is no Dock icon competing for attention. There is no main window demanding to be open or closed. The app is there when you need it and invisible when you do not.

This is also why some of the most beloved tiny Mac apps in the last decade have been menu bar apps. The form factor matches the mission. We wrote about how to choose a menu bar todo app for a longer treatment of why this works.

Why the trend is coming back

For a few years it looked like the tiny-app model was dying. Subscription pressure was eating the indie market. App Store changes made the economics harder. Apple kept demoing big productivity apps from name brands at every WWDC keynote.

But the last two years have quietly reversed the trend. A few things changed:

Subscription fatigue became real and measurable. Customers started cancelling subscriptions in noticeable volume.
On-device AI got cheap. Apps that previously needed a cloud LLM bill can now do the same work locally with Apple’s Foundation Models framework, removing the most common excuse for “we have to charge monthly to cover inference costs.”
The new wave of indie developers grew up watching the previous wave burn out trying to be platforms. They picked smaller scopes on purpose.

The result is that 2025 and 2026 have been quietly good years for tiny Mac apps. New ones launch every month. Old ones get small thoughtful updates. The model keeps working because the people who buy these apps actively want it to.

What this looks like for someone shopping

If you are looking at two apps that do roughly the same thing and one is a “platform” with five tabs and a paywall and the other is a single popover that does the same job, the platform is not the one that will still be in your menu bar in three years. The platform will pivot toward what its B2B customers want. The popover will quietly stay focused.

This is not a universal rule. Some of the best Mac apps ever made have been big, ambitious, and worth every dollar. Logic Pro is not a tiny app. Final Cut Pro is not a tiny app. Things 3 is somewhere in the middle and excellent. The point is not that bigger is bad. The point is that “small and unchanging” is a feature category in itself, not a sign of an app that has not grown up yet.

If you build software, the lesson is even simpler: smaller scope, longer tail. An app that does one thing well for ten years is worth more than five apps that did six things adequately for two years. The tiny utility has been outliving the redesigned platform on the Mac for thirty years. There is no obvious reason that will change.

If you use software, the lesson is to trust your instinct when an app feels right. The tiny one that just sits there and works is usually the one that will keep doing that. The one with seventeen tabs and a “Pro tier” probably will not.

TodoBar is built in this lineage. One menu bar app. One popover. No projects, no tags, no kanban board. It will not become a platform. It will not get a “Pro tier” with a separate paywall. The free tier covers most users. The single one-time unlock covers the power users. Nothing else gets added unless it makes the focused version better, not bigger.