pro · the engineering behind the tools
Built to a standard, not a deadline
These are the tools I build when I build them for myself: a web server, an embedded store, a record format, a pair of front-end tools, and the discipline that runs the work. This is the account of how each one holds, written for people who read source, not for a feature grid.
Each tool's page answers the same five questions: what it was built to solve, what makes it particular, what it measurably delivers, where it stands in its field, and what it deliberately refuses. No claim appears that I could not defend in a technical interview.
The tools
-
ZERVO+
A single-binary web server: a sandboxed Lua guest inside a Rust host, SQLite in the same process, HTTP/1.1, 2 and 3 from one file. This site runs on it.
Read the page -
TRIC+
An embedded key-value store in Rust that decides where each value lives, in memory or across a socket, so the caller does not have to.
Page in preparation -
GBLN
A record format for the age of language models: type-safe, deterministic to parse, and thrifty with tokens where JSON is wasteful.
Page in preparation -
minline
Front-end templating with nothing to compile: define a behaviour with
Page in preparationdef(), reference it with adata-mlattribute, done. -
htm/a
Behaviour as plain attributes on standard HTML elements. No JSX and no build step; the markup stays semantic and the server does the rest.
Page in preparation -
leanwerk
A works-discipline doctrine and the Rust CLI that enforces it: a deterministic control surface over a project's state, driven by a human or an attached model through one small set of commands.
Page in preparation