Why I Build Small, Local Software That Does One Thing

The temptation is to build everything

When generating code is nearly free, the natural pull is toward more. More features, more settings, more surface area, because none of it seems to cost anything up front.

But the code is the cheap part. Everything after generation is where the real cost lives: supporting it, explaining it, keeping it secure, fixing it when it breaks, and deciding what it should refuse to do. A model can write a feature in a minute. It cannot carry that feature for the next three years.

So the more useful discipline in an AI-assisted world is not writing code faster. It is deciding what not to build. Small scope is how I keep that decision honest.

One app, one job

Look at what I have actually put out, and the pattern is hard to miss.

• Comoji adds Slack-style colon emoji shortcuts to the text fields you already type in. That is all it does.
• Burly takes a link you click and opens it in the right browser profile. That is all it does.
• Premail filters the noise out of your email before it reaches your inbox. That is all it does.

None of these is trying to become a platform. Each one solves a single, specific annoyance and then gets out of the way. You can explain any of them in one sentence, which is not an accident. If I cannot describe a tool in one sentence, I usually have not decided what it is yet.

A tool that does one thing is also a tool you can finish. A tool that does everything is a tool you maintain forever and never quite get right.

Local by default

The second thing these apps share is that they run on your device and keep your data there. Comoji does its autocomplete locally and your typing never leaves the Mac. Burly routes your links on the machine and no URL is sent anywhere. Premail triages your mail on your own computer instead of piping it through someone else's servers.

This is the same instinct behind StockCar, which I wrote about separately: no account, no linking, your positions are not stored on a server. I keep landing in the same place because I keep asking the same question.

Before I add anything that needs a server or a login, I make myself answer:

• Does this feature actually require collecting data, or does it just make it convenient for me?
• If we store this, who becomes responsible for protecting it?
• What is the worst thing that happens if that store leaks?
• Would the user be surprised to learn this leaves their machine?

Most of the time the honest answer is that the account exists for the company's benefit, not the user's. Local by default removes an entire category of risk, because data you never collect is data you can never lose.

Small is a business strategy, not a consolation prize

It is easy to read "small, local, single-purpose" as the modest option, the thing you settle for when you cannot build something bigger. I see it the other way around.

A small tool is one a single builder can own end to end. That means:

• it can actually ship, instead of living forever in a half-built state
• it can be understood completely, so bugs have nowhere to hide
• it can be maintained without a team, which keeps the economics sane
• it can be trusted, because there is not much surface for it to betray you

With AI accelerating the parts that used to take a team, one person can now design, build, and ship a polished native app. But that leverage only holds if the app stays small enough for one person to keep holding. Scope is the variable that decides whether AI leverage compounds or collapses.

What "done" means for a tool like this

For a single-purpose app, done is a real state, not a moving target. Done means the one thing it promised works reliably, feels fast, and stays out of your way.

That makes the hardest work saying no. Comoji could grow a settings panel with forty options. Burly could try to manage your browsers instead of just routing links to them. Premail could become a whole new mail client. Every one of those additions would make the app bigger and the promise blurrier.

Signing and notarizing a Mac app, making a picker respond instantly, filtering mail quietly enough that you forget it is running: that polish is where the time should go. Restraint is not the absence of ambition. For this kind of software, restraint is the ambition.

The trust dividend

There is a compounding benefit to building this way that is easy to overlook. When an app is small, local, and account-free, a person can adopt it without a leap of faith.

There is no signup to abandon, no data to hand over, no wondering what happens to your information later. You download it, it does its job, and it does not phone home. That lowers the cost of trying it to almost nothing, and it means the trust you earn is real rather than extracted.

In a moment where AI makes it easy to flood the world with generic, data-hungry apps, the scarce thing is software people are actually comfortable letting into their day. Small and local is how I try to build that comfort in from the start.

The rule I keep coming back to

Cheap generation changes how fast you can build. It does not change what is worth building. If anything, when everyone can produce more, the discipline to produce less of the right thing becomes the differentiator.

So I keep applying the same test to anything new I start:

1. Can I say what it does in one sentence?
2. Can it run on the user's machine without an account?
3. Can one person own it completely?
4. Do I know what "done" looks like?

When the answer to all four is yes, the tool tends to be worth shipping. When it is not, I am usually about to build something bigger than I can stand behind.

Small, local, and finished beats big, hosted, and endless. That is the bet, and I keep making it.

← All postsNext: Teaching My Kids to Build With AI →