System

The origin, 1998

I started running companies in 1998, an architectural lighting and controls business first. At some point the ordering software you could buy stopped being worth the fight. It assumed a business that worked a certain way, and ours didn't. The standard answer was to bend the business until it fit the software. That never made sense to me. How we worked was the advantage. The software wanted to sand it off.

So I had a system built to my spec instead: cloud ordering, described from how the work actually moved. I wasn't the programmer. I was the one who knew what the software needed to do. That turns out to be the harder half.

The habit stuck. Every company since has run on at least one tool that didn't exist until we described it.

What thirty years taught me

Metalwork taught me the most. Stoller Metals made decorative metal surfacing: blackened bronze and brass, steel panels, metal veneer. The kind of material an architect specifies and a building wears for decades. Ours ended up in hospital interiors, a national laboratory, and Atherton living rooms. Physical product teaches economics that software never does. A mistake in software costs a rewrite. A mistake in product costs material, shop time, freight, and a customer waiting while it gets made twice.

And when something went wrong, it was almost never the making. What failed was upstream: something ambiguous in a spec, something assumed instead of asked, a decision made by default because nobody noticed it was a decision. The doing was rarely the problem. The deciding was.

The other lesson took longer. Plenty of things ran well because I was watching them. Those weren't systems. They were habits with my face on them, and they lasted exactly as long as my attention did. What survived was what anyone could run: written down, boring, hard to do wrong. That distinction is most of what I know about operating, and it took three companies to learn it.

AI didn't change what I believe about any of this. It changed what one person can do about it.

What I run

My own shop is one person on one machine. No infrastructure to speak of, no user accounts, no handoffs. I know where everything is and what state it's in, because I'm the only one who touches it.

Inside that shop the discipline is real. Every project gets a sensitivity tier before work starts. Sources get custody: the original to controlled storage, the converted copy committed with an ID, so a claim can be traced back to the thing it came from. Decisions get written down with a date, because a decision you can't find gets relitigated by whoever forgot it. Specs get reviewed by two other models before anything is built from them. Changes run isolated, so a mistake gets thrown away instead of unpicked. Backups run on a schedule I don't manage.

It runs on Claude Code, Codex and Gemini for review, git worktrees, an encrypted remote, local speech-to-text. Named so you know it's real, not a philosophy.

And none of it is a product. It works because of a skill I use every day, working with these tools. It is very effective, and it is not scalable beyond me. I wouldn't install it in anyone else's company.

What I'd install

What goes into a business is different. It starts where the 1998 ordering system started: with how the place actually works, not with what off-the-shelf software assumes. And it has to hold up without me in the room, run by people whose job isn't AI.

That rules out most of what demos well. A tool that needs its builder standing next to it is a performance, not a tool. A tool that needs the operator to be good at AI is my shop again, and my shop stays home. What earns its place in a business is duller: it does one job the team actually has, nobody needs training on it twice, and it keeps working after the person who asked for it stops checking.

The test is whether ownership can transfer, not whether attention can disappear. Nothing runs on zero attention. The question is whether someone else can take the thing over, run it, and fix it. If ownership can move, it was a system. If it can't, it was attention dressed up as structure. I've built both kinds. Once you've watched the second kind die, you check for it everywhere.

Why I publish the tooling

The tools I build for my own operation get published when they're worth publishing. This site lists public repositories only. If a project is private it isn't listed here, not even by name. A portfolio that lists work you can't look at isn't a portfolio.