I built my own publishing system, then decided to share it.

The problem

Running several sites by hand means the same small failures arrive in rotation: a post that breaks the build the minute it publishes, a deploy that half-uploads, a design that drifts because someone typed a pixel value. Each is minor. Together they are the reason a publishing routine can't be trusted to run while you sleep.

I wanted a system where the safe path was the only path. Edit locally, check everything before anything goes live, and have a bad release undo itself.

What I built

Site Studio is a local editor and release pipeline for static sites. The parts that carry the idea:

• Gates. Source, build and live checks run on every release, and a failed content check rolls the site back to the previous build.
• A block schema with no style fields. Content goes in; the look comes from the site's theme. An edit can't break the design because the editor has no way to say how anything looks.
• A release queue. A scheduled post is proven on a copy of the site before its time is accepted, so the failure shows up at planning time instead of at publish time.

It is a large codebase, roughly 230,000 lines with its own test suite, and it publishes real sites today.

How AI fit in

AI was a collaborator at the rough-draft stage, and I did the rest as an editor and architect: deciding what to build, reading what came back, rewriting what was wrong and turning every lesson into a rule or a check. Claude, Antigravity and GitHub Copilot all did real work on it, each in different places. Every one of them can write a plausible mistake, so the code gets reviewed as thoroughly as the goals and time allow, and the checks run whether or not a person feels confident.

The most useful habit was not a prompt. When something went wrong once, it became a gate, so the lesson stopped depending on anyone remembering it. The pipeline's checks are the written-down memory of every mistake it has already made.

The product itself runs no AI. That was a deliberate choice: you can trust a release check more when it does the same thing every time.

From internal tool to product

A tool built for one operator is full of assumptions that stop being true the moment someone else installs it: a private registry, a single hosting setup, my own machine. Turning it into a product means finding each of those and putting a seam in front of it. That work is under way, and the plan for it is the interesting part. It starts with the question of what a stranger would pay for when a free alternative exists, and the first test of that is a waitlist, not a launch.

What this shows

Taking a business problem, designing the system around it, building it with AI in the loop, and being honest about what it does and doesn't do. That is the same shape as the work I do with clients.