Small batch, on purpose.

Most software is built to be sold, then maintained until it can be sold again. I make the other kind: small tools that do one thing, that you can understand, and that don't need a roadmap to justify themselves.

How the work happens

One person, start to finish. Design and engineering aren't handed between people here, which means the details that usually get lost in translation — the empty state, the keyboard path, the error nobody planned for — belong to the same person who drew the happy path.

Everything ships small. A tool that's useful at version one is worth more than a platform that's impressive at version three and never arrives.

About the machines

I use AI constantly, and I'd rather say so than let you assume otherwise. It writes tests, sketches the boring three-quarters of a component, and argues with me about naming. It's the best pair I've ever had at two in the morning.

What it doesn't do is decide. Every line here has been read by me, and anything I couldn't explain to you got deleted rather than shipped. The interesting question was never whether a machine can write the code — it's who stays accountable for it afterwards. That's still a person. It's this one.

What that rules out

No accounts where a file would do. No telemetry that serves me rather than the person using the thing. Mockingboard has no backend at all — your images never leave the browser, because there was no good reason for them to.

An industry that treats attention as a raw material has made a lot of software that's very good at being difficult to leave. I'm not interested in building that, and I'd rather lose the work than pretend engagement and usefulness are the same number.

It also rules out volume. There's one pair of hands, so the roster stays short on purpose.

The name

Small batch, made by someone paying attention, better when it hasn't been sitting around: the standards a roaster is held to are not a bad set to borrow. The packaging conceit is a joke. The standard isn't.