August 4, 2026
Let your client edit the vibe-coded site you built them
Vibe-coding changed the economics of a one-off site. An afternoon of prompting, a bit of taste, and you ship something bespoke — hand-shaped, fast, exactly the thing the client asked for. No page builder, no theme, no compromise.
And then it just sits there. Beautiful, and completely frozen. The client wants to change the opening hours, and they can’t touch a single character without coming back to you. The thing you made for them is the one thing they can’t use.
A CMS is a big hammer for a small nail
The reflex is to reach for a CMS. But a CMS is built for a content team running a content operation — schemas, models, roles, a build pipeline, an admin panel to learn. Fitting one onto a finished bespoke site means dismantling the site and rebuilding it around the CMS.
It also quietly undoes the thing that made the site worth making. You vibe-coded a specific artifact; a headless CMS turns it back into fields in a database and a template that renders them. You spent the effort to escape the generic. Why pour the content back into a generic box?
The site you shipped is already the source of truth. It’s versioned, it’s fast, it’s yours. The only missing piece is a safe way for a non-developer to edit the words inside it.
Handing over the content, not the repo
The move is to give the client the content, never the repo.
You connect the repository through a GitHub App scoped to the repos you pick.
It reads the code and finds the human-facing values — headlines, paragraphs,
image sources, list items — wherever they actually live, in the markup or in the
const array your template maps over. You decide which of those the client may
touch, label them in plain words, and lock the rest.
Your client signs in with Google. No git, no branches, no commits — a live preview of their own site, editable regions lighting up on hover. They fix a line, drop a new photo, hit Publish. Every publish becomes one atomic commit, signed, on your branch.
Why it won’t wreck your site
The scary part of “let a non-developer write to a production repo” is the writing. So the write path is deliberately dumb: parse, anchor, resolve, splice, commit. There is no language model anywhere near it. An LLM would be right most of the time, and “most of the time” is exactly how a convincing wrong edit lands on someone’s live site.
Every value is pinned to a deterministic anchor in the syntax tree. At publish, each anchor is re-resolved against the current code. Resolves cleanly, it writes — byte-exact around the value. Anything ambiguous, it refuses to write rather than guess. Every publish is one commit with a one-tap rollback, and if you changed the code in the meantime, your work wins — conflicting edits are held for you, never applied over the top.
So you keep pushing, the client keeps editing, and neither of you steps on the other. The site stays exactly what you vibe-coded. It just stops being frozen.