I have a clipboard manager on my Mac. It does one thing: it remembers what I’ve copied. I can scroll back through my history, pin items I use often, and paste them with a keyboard shortcut. That’s it. The entire application is around 1,200 lines of Swift.
I also have a menu bar manager. It hides the icons I don’t want to see and shows the ones I do. That’s about 900 lines. I have a screen saver that turns my camera feed into ASCII art — admittedly that one’s more complex, but the core rendering logic is still only a few hundred lines of code. I have a utility that stops me accidentally quitting apps with commandQ. That’s 600 lines.
None of these applications will ever appear on a “Top 10 Productivity Suites” list. None of them have onboarding flows, account systems, telemetry dashboards, or subscription tiers. None of them phone home. They are small, focused programs that do exactly one thing, and I think that’s worth defending.
We’ve collectively decided that software should do more. Every major application is in a state of perpetual expansion — adding features, integrating services, absorbing adjacent functionality like some kind of digital amoeba. Your note-taking app wants to be a project manager. Your project manager wants to be a wiki. Your wiki wants to be a database. Your database wants to be a note-taking app. The ouroboros of productivity software.
The logic is understandable. If you already have the user’s attention, why not give them more reasons to stay? Every feature is a retention hook. Every integration is a switching cost. From a business perspective, it makes perfect sense.
From a user’s perspective, it’s exhausting.
I don’t want my clipboard manager to have a “Smart Suggestions” panel powered by a language model. I don’t want my window manager to sync my layout preferences to the cloud. I don’t want my screen saver to integrate with my photo library, my social feeds, and my Spotify listening history. I just want these tools to do their job and then get out of the way.
When I say small, I mean small in every dimension that matters.
Small in scope. Each app solves one problem. ClipMan manages your clipboard. WindowPin floats a window. CalendarUpcoming watches your calendar. ActiveSpace shows your space number. There’s no feature overlap between them because there’s no feature creep within them. If I catch myself thinking “while I’m in here, I could also add…” — that’s usually a sign I should stop and build a separate thing instead.
Small in code. Most of these apps are under 1,500 lines of Swift. That’s not a constraint I impose artificially; it’s what happens when you build something that does one thing well and then stops. There’s no dead code hanging around from features that were added speculatively and never removed. There’s no abstraction layer over an abstraction layer over a framework over a platform API. The code does what it does, directly, and you can read the whole thing in an afternoon.
Small in footprint. These apps launch instantly, use negligible memory, and don’t run background processes unless they genuinely need to. QuitProtect is literally just an event tap — it intercepts commandQ, asks you to confirm, and does nothing else. It has no business using more than a few megabytes of RAM, and it doesn’t.
Small in dependencies. Most of these apps have zero external dependencies. No CocoaPods, no Carthage, no third-party frameworks. Just Swift, AppKit or SwiftUI, and the system APIs that Apple provides. The only shared code is JorvikKit — a small component library I built to standardise things like the About window, the settings view, and the update checker across all the apps. It’s around 800 lines. That’s the entire shared infrastructure.
Here’s a thing I’ve noticed: small software doesn’t break in interesting ways.
When something goes wrong with ClipMan, the failure mode is obvious. The clipboard history didn’t update. Or the keyboard shortcut stopped responding. There are only so many things that can fail when the total surface area of the application is a thousand lines of code and a handful of system API calls. I can hold the entire program in my head, trace the problem, and fix it — usually in minutes.
Compare that to debugging an issue in a large application with dozens of modules, plugin systems, sync engines, and background workers. You’re not debugging a program at that point. You’re debugging an ecosystem. The bug might be in your code, or in a dependency, or in the interaction between two features that were never designed to coexist, or in a race condition between your sync engine and your local cache. The search space is enormous.
Small programs have small search spaces. That’s not a minor advantage — it’s a fundamental one.
The Unix philosophy — write programs that do one thing and do it well — is one of those ideas that everyone nods along to and almost nobody follows when building desktop applications. We accept it for command-line tools. Nobody complains that grep can’t also sort its output, because sort exists and pipes are cheap. But the moment we move to GUI applications, we abandon composability in favour of monoliths.
I think that’s partly because GUI apps can’t pipe into each other the way command-line tools can. There’s no visual equivalent of |. But the principle still holds, even if the mechanism is different. On macOS, the mechanism is the menu bar. Each of my utilities lives there as a small, independent icon. They don’t know about each other. They don’t need to. They coordinate, if at all, through the operating system itself — through the clipboard, through keyboard shortcuts, through the window manager, through the accessibility APIs.
ClipMan doesn’t need to know that HyperCaps exists. But if you’ve remapped Caps Lock to a Hyper Key with HyperCaps, you can assign a conflict-free shortcut to summon ClipMan’s history. They collaborate. Not through some integration SDK or plugin architecture, but through the operating system doing what operating systems are supposed to do.
Every feature you add is a feature you must maintain. For ever. It needs to work on the next version of macOS. It needs to handle edge cases you haven’t thought of yet. It needs to not break the other features. It needs documentation, even if that documentation is just a tooltip. It needs testing, even if that testing is just you using it for a week and seeing if anything catches fire.
When your entire app is 1,200 lines, the maintenance burden is close to zero. I can update ClipMan for a new macOS release in an evening. I can audit the entire codebase for deprecated API usage in twenty minutes. I can refactor the whole thing — if I ever needed to — in a weekend.
This matters more than people think, especially for independent developers. I don’t have a team. I don’t have QA. I don’t have a product manager deciding which features to deprecate. The complexity I add is complexity I personally carry, indefinitely. Keeping things small isn’t just an aesthetic preference — it’s a survival strategy.
I should be honest about the trade-offs, because there are some.
You give up discoverability. Nobody’s going to stumble across QuitProtect in the App Store’s “Top Charts” and think “ah yes, this is what my life was missing.” Small, single-purpose utilities solve problems that most people don’t know they have until they have them. Marketing a clipboard manager is inherently harder than marketing an “all-in-one productivity suite” because the pitch is narrower. “It remembers what you copied” doesn’t have the same ring as “transforms the way you work.”
You give up the upsell path. There’s no natural progression from “free clipboard manager” to “premium clipboard manager with AI-powered paste suggestions and team sync.” The app does what it does. If I charged for it, the price would be the price, and there would be nothing else to sell. As it happens, everything I’ve built is free and open source — but even if it weren’t, the economics of small software are fundamentally different from the economics of platforms.
You give up the network effects. Notion is valuable partly because your whole team is on Notion. Slack is sticky because your whole company uses Slack. A clipboard manager has no network effects. It’s useful to you, on your machine, regardless of what anyone else is running. That’s a feature, but it’s also a ceiling.
I’m at peace with all of this. These are tools, not platforms. They’re meant to be useful, not viral.
I keep coming back to the line count, not because lines of code are a meaningful metric in isolation — they’re not — but because they’re a useful proxy for something that is meaningful: comprehensibility.
A program that fits in 1,200 lines can be understood by a single person in a single sitting. Not skimmed. Not “got the gist of.” Understood. Every function, every state transition, every edge case. You can read it top to bottom and know, with confidence, what this program does and what it doesn’t do. You can verify that it respects your privacy because you can see, right there, that it never opens a network connection. You can verify that it doesn’t do anything unexpected on launch because the launch sequence is forty lines of code and all of them are obvious.
This is an extraordinary property for software to have, and almost nothing has it anymore. We’ve normalised applications with hundreds of thousands of lines of code, hundreds of dependencies, build systems that take minutes to run, and behaviours that even their own developers can’t fully predict. We’ve normalised not knowing what our software does.
I’d like to un-normalise that, at least for the small corner of the world where my tools live.
I should address the elephant in the room, and the elephant is wrapped in Chromium.
A significant proportion of modern “desktop” applications are web apps wearing a trench coat. They ship an entire browser engine — sometimes hundreds of megabytes of it — to render what amounts to a styled div with some JavaScript behind it. Your chat app, your music player, your note-taking tool, your code editor’s code editor: many of them are Chrome tabs that have been granted the dignity of their own Dock icon.
I understand why this happens. Write once, run everywhere. Web developers are abundant. The DOM is well-understood. From a business perspective, shipping Electron1 makes complete sense.
From a “my laptop has 8GB of RAM and four of those are currently occupied by a to-do list” perspective, it’s less compelling.
Every Jorvik utility is native Swift. Not because I have an ideological objection to web technologies — I literally build web applications for a living — but because a menu bar utility that monitors your clipboard has no business bundling a browser engine. ClipMan uses about 20MB of RAM. A comparable Electron app would use 150MB before it displayed a single item. That’s not a rounding error. That’s a philosophy of resource consumption that I don’t want to participate in when the alternative is right there, built into the operating system, waiting to be used.
Native apps start faster, use less memory, integrate better with the OS, and respect the platform’s conventions. They feel like part of your computer rather than something visiting from the cloud. For small utilities especially — apps that should be invisible — native isn’t a luxury. It’s the minimum viable respect for the user’s machine.
None of this happens by accident. Small software requires discipline — specifically, the discipline to stop.
The hardest part of building ClipMan wasn’t the clipboard monitoring, or the keyboard shortcut handling, or the menu bar UI. It was resisting the urge to add a search function. And then a tagging system. And then categories. And then sync across devices. Every one of those features would be useful to someone. Every one of them would make the app larger, more complex, harder to maintain, and slower to start. Every one of them would chip away at the thing that makes it good: that it’s simple enough to be invisible.
The best tools are the ones you forget are running. You don’t think about your clipboard manager. You just press the shortcut and the thing you copied twenty minutes ago is right there. You don’t think about your menu bar manager. Your menu bar is just… tidy. The tool disappears into the workflow. That kind of invisibility requires restraint. Features are visible. Simplicity is not.
There’s one more thing worth mentioning. The collection matters.
Any one of these utilities is a minor convenience. A clipboard manager saves you a few seconds here and there. A window pinning tool saves you from commandtab cycling. A quit protector saves you from losing unsaved work once a month. Individually, they’re nice to have.
But running a dozen small, focused tools — each doing its one thing reliably, each using negligible resources, each maintainable in an evening — creates something greater than the sum of its parts. Your Mac starts working the way you think it should. The rough edges get filed down. The minor annoyances that you’d learned to tolerate simply stop happening.
That’s the case for small software. Not that any single tool will change your life, but that a philosophy of building focused, comprehensible, minimal tools creates an environment where your computer works for rather than against you. Where you can trust what’s running because you can understand what’s running. Where nothing is trying to become a platform, nothing is competing for your attention, and nothing is doing more than it should.
If I am ever asked why I don’t consolidate everything into a single “Jorvik Utilities” app with a unified preferences pane and a tidy feature list. The answer will be that consolidation is the first step toward the bloat I’m trying to avoid. The moment you put twelve tools behind one icon, you’ve created pressure to make them aware of each other, to share state, to offer a unified experience. You’ve created a platform. And platforms, by their nature, grow.
Twelve utilities, a screensaver, and a shared library that holds them together. Each one small. Each one finished. Each one doing exactly what it says on the tin.
That’s not a limitation. That’s the whole point.
I’ve got nothing against Electron. I’ve built Electron apps. It has it’s place. But it’s place is not a wrapper around a clipboard manager. ↩