I build small software, mostly tools I wanted and couldn’t find. A Markdown viewer that opens fast on Wayland and does not try to become an editor or a knowledge base. A Nextcloud app that pulls a file from a URL, so the machine I am sitting at doesn’t have to stay awake for the download, and that resists turning into a general download manager. A publishing layer that keeps WordPress as an editor and puts plain static files on the public internet instead.
One of them is a shell that hallucinates the entire computer, which is not serious at all.
What they have in common is a preference: small enough to understand, capable enough to be useful. That does not mean making everything smaller. Some problems are genuinely complicated, and a tool that pretends otherwise is just broken: a calendar needs time zones, a photo editor needs to handle real image formats, a mail client needs to survive decades of malformed MIME. What interests me is the cost that never shows up on the feature list. Every capability is one more thing that has to be understood, maintained, secured, documented, and kept working with everything already there.
So when a feature would cost more to keep working than it’s worth, I would rather leave it out, or leave the last part of it to the user and say so plainly. One post here is about a checkbox whose real design turned out to be a browser tab that somebody has to keep open.
That’s hard to argue in the abstract, so this blog does the specific version instead. Most posts are one decision from one release: what it cost, what I left out, and what I got wrong. Some are about Stelae or static WordPress, some about open source, compiler bootstrapping or small tools, and some about a project that exists only because it was funny.
