Briter — Or, What Happens When You Diagnose the Wrong Problem
April 18, 2026 · 5 min read
"Writing is easy. All you have to do is cross out the wrong words." — Mark Twain, allegedly
Also you have to open your editor, and commit, and push, and wait for a container to rebuild. Or you did. I built Briter so I could go back to just crossing out the wrong words.
The Setup
A few weeks ago I had a conversation with a colleague about how he manages to publish so consistently on his own blog. His answer surprised me. He uses a small, opinionated blogging app, pays about nine dollars a year for it, and says it gives him around ninety percent of what he wants. No self-hosting. No elaborate stack. Just a tool that stays out of his way while he writes.
That conversation held up a mirror I had been avoiding. Writing a note on this site meant leaving the writer's chair and sitting down in the engineer's chair for a sequence of small technical rituals, and by the time I came back the original momentum had cooled. Every screenshot was its own errand. Every typo required a full redeployment. None of it was difficult, and all of it was enough, in aggregate, to keep me from finishing drafts that were already almost done. My colleague's setup is built around the act of writing. Mine was built around the act of deploying, which I only tolerate.
So I sat down to rearrange it. What came out of that is a small publishing app I have been calling Briter. It lives inside the site, behind a login, and it lets me write, paste screenshots, preview, schedule, and publish without ever leaving the writer's chair.
The Thinking
A few principles are worth naming, because they are the ones I keep returning to when the scope starts to drift.
My writing should live as plain files in a repository I already own, not in a database I would eventually regret. Briter is a thin layer that writes to disk and lets git take care of the rest. If it disappears tomorrow, every note is still exactly where it was.
The feel of the tool matters more than the feature list. I spent some time looking at rich editors with drag handles and floating toolbars and decided, honestly, that I find them tiring. What I actually want is a text box and a live preview beside it. There was no reason to fight it.
The third one I almost got wrong. I had planned to skip image handling and add it later, but when I looked at the drafts I had failed to publish, almost all of them had stalled on a screenshot. Images were not an afterthought. They were the feature that made publishing feel heavy, so I made paste-and-go the first thing that worked.
And publishing should not rebuild the world. A tool that makes you wait for it teaches you to hesitate before using it, and I had been hesitating for long enough.
The Work
The work itself took one long, focused session. I will not walk through the construction; the technical companion to this post does that, for anyone who wants to nerd out. What is worth saying here is what the experience of using it is like.
It feels, almost disappointingly, unremarkable. I log in. I write. I paste a screenshot, and it appears in the draft without any ceremony. I save, and a few seconds later the note is live. The thing that used to be a small expedition is now a single continuous motion.
What I did not expect is how quickly this changed my behaviour. When a task costs something, you batch it. You wait until you have several small edits stored up and then make one joyless trip to clear them. When the same task costs almost nothing, you stop batching. You simply do each small thing as you notice it, the way you would adjust a sentence in a document you are already editing.
The Edge
Right now Briter is welded to this site, with my paths and my assumptions baked in. But there is nothing site-specific about the underlying idea. Anyone who writes on their own domain, in plain markdown, on a small server somewhere, has roughly the same problem I had. So over the coming months I plan to pull it out into its own project and release it openly. It will not have ninety percent of what most people need; that is explicitly not the point. It will do a small number of things well, for people whose starting point looks like mine.
Beyond that I have no grand plans. What I am interested in is the practice of building these things. Making this site taught me a great deal I did not know. Building Briter taught me more. Whatever I make next will teach me something else. The output is useful, but the output is not really the point. The point is that I keep showing up at the workbench.
This is the first post I am publishing through Briter itself, and it is worth saying that the conversation which started all of this asked a question I had been avoiding: what is it that I actually need? The honest answer, once I was willing to sit with it, was not a bigger audience or a better stack. It was a shorter distance between thinking and publishing. That is what Briter is.