moomou

(ノ≧∇≦)ノ ミ ┸┸

Software for One

Posted at — Apr 28, 2026

Introduction #

In the age of coding agents, building software has never been cheaper or easier. I can go from an idea to shipping working software in an afternoon. I wanted to document a couple of these in this post and argue that, in the era of AI coding, more software will be written and increasingly cater to a smaller audience.

WinGroup #

WinGroup is a Mission Control–style window overlay and a per-app hotkey launcher. It replaces Apptivate, the last Rosetta-translated app on my Mac, and adds two features I could not find in any single shipping app: AI auto-grouping of open windows by project or task, and a way to move a whole group of windows to another desktop space in one action.

The hotkey behavior is the one I have been training my fingers for over five years: ⌥V to VSCode, ⌥C to Chrome, etc. Apptivate works fine; I just wanted the last Rosetta app off my Mac. Replicating its hotkey behavior reliably on Sonoma and Sequoia turned out to be the hard part of the project.

The “for one” angle is that the hotkey set is mine, the auto-grouping shells out to my locally-installed copilot CLI instead of going through a cloud LLM API, and the overlay UI is tuned to my monitor layout. There is no preferences window. When I want to change a hotkey, I edit a JSON file.

I had never written a line of Swift before this and had no prior experience with macOS APIs. The first usable version came together in an afternoon: I pointed a coding agent at “build me a menu-bar app that does X” and iterated from there. The agent wrote the Swift; I read it, asked questions, and pushed back when something looked wrong.

The hard part underneath, eight layers of fallback to make per-app window activation reliable on Sonoma and Sequoia, would have taken me weeks of grepping through yabai, AltTab, and Hammerspoon source on my own. With an agent doing the cross-referencing, it was a few evenings. The agent didn’t solve the activation problem; the layered cascade still came from reading other people’s code and reasoning about timing bugs. But it collapsed the discovery loop enough to make the project tractable in evenings rather than months.

Jingpian #

Jingpian is an Electron app I built as a general-purpose Google Lens for the desktop. I press Ctrl+Shift+9, drag a rectangle on the screen, and the captured region gets sent to a multimodal model. It comes back as a translation, an enhanced version of the image, or extracted text, depending on which mode is active. In practice the mode I use most is live OCR for translation.

Because I am the only user, jingpian doesn’t bother integrating with any model API directly. It shells out to my locally-installed copilot CLI, which already has my credentials and rate limits sorted out. There is no API key management, no secure token storage, no provider abstraction, no fallback when one model is rate-limited. A version of this meant for other people would have to do all of that, plus a data-handling policy for screen pixels going to a third party.

What I have learned #

A few patterns I noticed across these two.

The product surface shrinks a lot. WinGroup has no preferences window. Jingpian has one hotkey. The configuration that would normally live in a settings UI lives in the source code, and I rebuild when I want to change it. This is fine, because the time between “I want this changed” and “it is changed” is under five minutes.

The data model can be opinionated in a way it can’t be in a product. There is no “what if a user wants X.” The only user is me, I don’t want X, the schema can reflect that.

You can use private and unstable APIs that a product can’t ship. WinGroup leans on a stack of private SkyLight calls that no app on the Mac App Store could reference.

You don’t need much architecture. When rewriting from scratch is a weekend, abstractions and plugin systems stop being worth their cost.

Reflection #

AI coding has made software easy and cheap enough to upend the assumptions you make about when to build versus when to buy. For most of my career I have assumed that “use the tool that exists” is the cheaper move, and “build the tool that fits” is the expensive one. That ratio has flipped for a surprisingly large class of problems. Not all of them. There are still plenty of categories where buying or installing the existing thing is correct, but enough that I keep noticing.

WinGroup alone would have been months of yak-shaving without an agent, and jingpian would have felt like a chore. With agents, both became things I now use and depend on every day. This is the start of the era of software for one, and I am excited to be building more of it.