Building a website builder where every instruction is undoable

Most website builders treat an edit as a mutation. You change a heading, move a photo, swap a colour, and the previous version is gone unless you remembered to snapshot the whole page. That works when you are clicking through a familiar UI. It gets brittle when the editor is a sentence: "make the photos bigger", "move the phone number to the top", "calmer".

I wanted those sentences to be first-class objects, not disposable prompts. That is the idea behind silo.host: you describe the site in plain words, watch the layout, design and content change, and keep every instruction so you can undo any of them.

Instructions are the history

In a conventional CMS, the source of truth is the current document. Undo, if it exists, is a short in-memory stack, or a full-site backup you restore all at once. Neither maps well to a conversation. If the third instruction improved the typography and the fifth one broke the header, you do not want to roll the whole site back to this morning. You want to drop the fifth instruction and keep the rest.

So the history is a list of instructions, in the order they were applied. Each one is kept, including the ones that did not work out. "Undo" means removing or reversing a specific entry and letting the site settle again, rather than inventing the inverse of a visual change after the fact.

That has a few practical consequences. You can read how the site got here, in the same language you used to edit it. A bad instruction is cheap: try "bigger photos", decide it is too much, and take it out. The same instruction can be reapplied later, or applied with a small wording change, without reconstructing the page by hand.

A shared structure, so design changes do not break pages

If every instruction rewrote the whole site as a fresh pile of HTML, undo would be messy and pages would drift. A typography change would risk rearranging the contact block. A new blog post would have no stable place to live. "Move the phone number to the top" would only be safe if "the top" and "the phone number" were real things, not whatever the last generation happened to emit.

The site therefore sits on a shared structure that instructions act on, rather than replace. Pages, the blog, navigation, and the repeating regions of the layout are the same objects before and after a design change. When you ask for a calmer look, the request restyles those objects. It should not invent a new information architecture, and it should not orphan a section that was already there.

That is also why hosting, pages and a blog belong in the same product, not as a theme plus a plugin plus a host. The structure has to exist before the first instruction, including a live address on day one, or there is nothing stable for the instructions to refer to. You can point your own domain at it later.

The constraint is deliberate. An instruction is not allowed to "just rewrite the homepage" if that rewrite would break the rest of the site. The model is closer to a series of patches over a known shape than to a sequence of full-page regenerations.

The same instructions, from Claude

Once instructions are the unit of work, it should not matter much where they come from. Typing them in the studio is the straightforward path. The same list can also be appended to from Claude, through an MCP connector, so you can work on the site from a conversation you are already in.

This is not a second editor. Claude does not keep its own copy of the layout. It issues instructions into the same history, against the same structure, and those instructions can be undone in the same way as the ones you typed yourself. If a request from Claude overshoots, you drop it. You do not have to reconcile two sources of truth.

That is the difference between "an AI that can also edit my site" and "one history with more than one way to append to it". The first design usually ends in a page that only the connector understands. The second keeps the studio, the conversation, and undo on the same path.

What I would still change

The history is only as useful as it is readable. A long list of near-duplicate instructions is hard to scan, and a very broad one ("make it better") is hard to undo precisely because it touched too much. I am still tightening how those cases are shown and grouped.

The structure also has to stay boring on purpose. Every time I have been tempted to let an instruction invent a new kind of page on the fly, I have had to weigh that against the next person's ability to undo it. For a website builder, I would rather have a slightly smaller set of things that stay intact than a more dramatic generation that you cannot take back.

If you want to try it, describe a site and watch what the instructions do to it: silo.host.