I've spent a couple of decades in enterprise tech, working across solutions engineering, infrastructure and cloud, contact center systems, and security. Somewhere along the way I got into building things myself, and these days I do it AI-native: I direct coding agents to write the software and keep a hand on the wheel, bringing the engineering judgment about where they get it right and where they get it wrong.
I like problems that start rough and get sharpened by building. A note, an annoyance, a "why doesn't this exist yet," and then something running.
I build and maintain a few focused organizations. Three are product families. Two are the shared ground they stand on β the contracts underneath, the interface on top. The last is the bench everything else sits at.
Declarative GUI testing and demo creator that runs the same plan on every platform.
AutoPilot describes a UI test as data β a JSON plan β instead of code, then runs that same plan against a native macOS app, an iPhone, an Android device, or a browser. It exists because XCTest, UiAutomator, and Playwright each solve one platform well and share nothing between them: a plan written for one is a rewrite for the next. The org holds a platform-agnostic core, a runner per platform, and a Homebrew tap.
Free-software control for stream decks and macro pads.
DeckLibre is an open replacement for the closed vendor software that ships with hardware macro pads, starting with the Ulanzi Stream Controller D200X. It's built to four ideas, in order: accessibility first, ease of use for the common flow with the depth kept behind an Advanced unlock, speed, and choice β a prosumer tool that hands you options instead of one opinionated path. The org also holds the plugins that drive real applications from the deck.
Accessible, open control for every instrument in the studio.
A family of open control surfaces for the tools of a production β
cameras (conductord), lights (LiteController), a light meter next,
audio and more to come. Each has its own control plane and stands on
its own: a WebSocket API and a screen-reader-first web UI, brand-generic
and scriptable, first-class on macOS, Linux, and Raspberry Pi. One more
surface speaks every product's control plane through that same shared
interface, conducting them as a single ensemble rather than a drawer of
separate apps.
A simple way in for the individual just getting into photography or video, an open API for the hacker who just wants to control and automate, one console for the small studio, and a full ensemble for the growing production.
Work in progress β each piece goes public as it reaches beta.
The shared contracts and doctrine (most) products here are built on.
Independent programs interoperate because they conform to the same
practices, not because they share code. This org holds the three
layers that make that true: design-doctrine (the principles β why
and the rules), blueprints (the shapes β how to build a recurring
kind of thing), and CommonTongue (the contracts β the versioned
schema and the per-language packages that realize it). The first two
you read. The third you depend on.
The accessible interface layer the products wear.
A product here ships no UI of its own β it publishes a self-describing
control surface, and SurfaceWorks turns that description into a live,
screen-reader-first interface, generically, with no product-specific
code. It holds Lucidity (the reference renderer), Palette (the
catalogue of control widgets a renderer draws), and Codex (the
cross-vendor vocabulary of what a control means). The vocabularies
are recommended and grow by pull request β align to them for interop,
or roll your own and still render.
Work in progress β the CommonTongue contract it renders is being finalized.
The bench: the one-offs that aren't part of a family.
Self-contained tools that were built once, for a real problem, and still work. Nothing here is trying to be a platform.

