I retired the visual page builder and kept its server running for one route

On November 8 I retired the visual page builder. Not parked, not moved to a branch - retired. build.html, builder.js, editor-*.js|css, puck-editor/.

The note I left in the repo says it plainly: the visual slice builder is retired as a product. What made it a decision rather than a cleanup: I could name a feature I had added to the builder every week for months, and I could not name a single page a stranger had paid for.

Eighteen complete templates sat in the pool, and none of them had a price on them anywhere on the internet. The builder was the most interesting thing in the repository and the least useful thing in the business.

What it actually cost to remove

Removing a product is not a file operation. It is a graph traversal, and the graph is the part nobody budgets for. Three things pointed at the builder.

Cloudflare tunnel ingress had a builder.prismicaudit.com hostname, with DNS pointed at it - both gone, and I copied the pre-change ingress to a JSON file first, because a tunnel ingress is the kind of config where "I'll remember what it was" is a lie.

The buyer-facing story also broke: with no editor, the only way to change the page is data/templates.json, one file, text between quotes. That is a real downgrade in flexibility. I am not going to pretend a JSON file is a better editing experience; it is a smaller support surface, which is a different claim.

The third thing is the one I would have missed if I had rushed: server.py still runs. Not from sentiment. site-next/app/api/order/route.js proxies order intake to 127.0.0.1:8791/api/order, so the process that used to serve the builder is still the process that catches orders. It now binds loopback only. Half of deleting a feature is finding what quietly still calls it.

Where the green build lied to me

The repository gate runs in about a second:

• templates.json must parse, hold exactly eighteen entries with ids t1..t18 contiguous and slugs unique
• every thumb and section image must exist on disk
• no conflict markers, no truncated markers pasted into docs

That gate passing tells me the data is coherent. It has never told me the page looks right, and for a while I treated those as the same statement.

So the gate now has to be able to fail on purpose: make test-gate hides one thumbnail and asserts a non-zero exit code. A gate nobody has watched go red is decoration. That test changed how I read every other green check from tooling - passing means the check ran, not that the thing works.

Same logic on styles: I only add scoped rules, and touching the shared stylesheet or theme variables counts as a global change that requires before/after screenshots of the whole site. A CSS diff cannot be reviewed by reading it. Two images can.

The constraint that made the choice

This runs on a two-core box with no display, so visual checks are one browser, serial, headless. CI stays on GitHub's runners - a self-hosted runner would share the machine and its credentials with the agent gateway that does the deploying, and I am not merging those blast radii to save a few seconds.

So the shipping path is static: build once, deploy an artifact. The storefront for the newest template is a single 12KB HTML file in dist/sale, deliberately untracked, because it is an artifact and the source tree is what deserves history. The consequence: the storefront has no version history. Accepted.

That page sells one layout for $29 with no checkout - email, invoice, ZIP. The gallery shows full 3,295px renders rather than hero crops, because a template buyer is buying the bottom of the page as much as the top: https://slicelab.prismicaudit.com/.

It is the same argument the audit tool makes over at https://prismicaudit.com/ - show the evidence, not the dashboard.

I cannot tell you the retirement increased sales; there is no data yet and I will not invent any. What I can attribute: one fewer product to keep alive, one process left running on purpose, and a page you can read in a text editor.