In our post on what to do when a business replies, there's a line we glossed over in a sentence. A Watford builder, mid-deal, asked whether he could upload photos to his own site without messaging us every time. Building a self-serve admin panel is normally a week of work for a senior developer, and a web agency would quote it as a separate four-figure project. Claude Code one-shot it in fifteen minutes that evening, deployed to /admin with a memorable password. The customer has been managing his own portfolio ever since.
We told that story as a one-off — a glimpse of what becomes possible when the marginal cost of engineering effort falls through the floor. But it didn't stay a one-off. The same request kept coming. "How do I add photos?" "How can it be regularly edited?" Two of the three questions almost every serious buyer asks are some version of can I change this myself once it's mine?
So we stopped rebuilding it from scratch each time and turned it into a repeatable, packaged skill. One command now adds a complete content management system to any site Klaudius builds. This post is what it does, how it actually works under the hood, and how to sell it.
What the business owner gets
A second, private address on their own website: yoursite.com/admin. They visit it, type a password, and land on a simple editor that mirrors their site section by section. Their phone number, their opening hours, the headline, the "about" paragraph, their services, their reviews, every photo and its caption. They change what they want, hit save, and the live site updates within seconds.
It's built for the person it's for. The owner of a roofing business is not a web developer, and the editor never asks them to be one. There are no page builders, no drag-and-drop grids to wrestle, no settings panels full of jargon. It's a column of labelled boxes with the current text already in them and a "save" button under each one. Photos upload straight from a phone camera roll — the single most-requested capability, because a tradesperson's best work photos live in their pocket, not on the open web.
Crucially, there is nothing for them to install, nothing to log into except their own site, and no monthly platform fee waiting to surprise them. It is their website, and now it's genuinely theirs to run.
How it works under the hood
The interesting engineering is in what doesn't break.
A normal worry with letting a non-technical owner edit a hand-built site is that their edits and your code will collide — that the next time you ship a change, you'll flatten everything they've typed, or that one bad input will white-screen the live site. The CMS is designed so neither can happen, and the design is worth understanding because it's the reason the feature is reliable rather than risky.
Content lives separately from code. The editable parts of the site — all that text, every photo — are not baked into the source. They're stored as a single content file plus uploaded images in Vercel Blob, the hosting platform's object storage. The site reads from that store when it renders. This decoupling is the whole trick: you can redeploy the site, ship a design change, even run a framework update, and the owner's edits survive untouched, because they were never in the code you redeployed. Equally, when the owner saves a change, nothing about the code changes — only the content file does. Code and content move independently, which is exactly what you want when two different people (you, and the owner) are each touching the site for different reasons.
The login is a real auth system, not a hardcoded password. The owner types a password, but behind that is a proper signed-session setup: an HMAC-signed cookie with an expiry, a gated /admin route, and a server-side check on every single save. It's the right amount of security for what this is — one owner editing one site they own — without dragging a non-technical person through account creation, email verification or a password manager. A login they can memorise, backed by real session signing they never have to think about.
Photos are handled where phones actually are. A modern phone photo is often 5 to 12 megabytes. Upload that raw and you'd hit the platform's request limits and slow the site down. So images are compressed and resized in the browser, on the owner's device, before they're ever sent. The owner just picks a photo; the editor quietly shrinks it to something web-sized first. The site stays fast and the upload always goes through.
A bad save can't take the site down. Content read back from storage is sanitised before it ever reaches the page, so a malformed or half-written edit falls back to safe defaults rather than throwing an error at a visitor. The public site is resilient to whatever happens in the editor by design.
No WordPress. No plugins to keep patched. No separate database to run or pay for. The storage sits inside the same hosting the site already uses, which is free at the volumes a small-business website will ever produce. The owner gets a real CMS with none of the overhead a real CMS normally drags along.
How you run it
One command, after the site is built and deployed: /cms, pointed at the client.
What makes it a genuine one-shot rather than a bespoke build every time is the split between what's fixed and what's variable. The plumbing — the auth, the storage wiring, the photo pipeline, the resilience — is identical on every site. It doesn't get reinvented; it gets installed. The only part that's specific to a given business is which content the owner should be able to edit, and that's something the skill works out by reading the site it's adding the editor to. A plumber's site and a hair salon's site get the same rock-solid foundation and a different set of editable fields, automatically.
So the command does the whole job end to end. It reads the finished site, works out the editable content, builds the matching editor, wires up the storage, sets a password, and redeploys. When it's done it hands you the password and a short note you can forward straight to the client. If a particular client wants something specific made editable that the site doesn't obviously expose — a seasonal banner, a price list, a notice at the top of the page — you just say so in plain language and it's included. You never touch the code yourself.
Because the architecture is fixed and proven, the result is the same every time: a working editor, live, with a password in your hand. The variability that used to make "build them a CMS" a scary, custom job has been engineered out.
Why this is a different kind of CMS
It's worth being precise about the differentiation, because "let people edit their own site" is not, by itself, new. Wix and Squarespace let owners edit. WordPress lets owners edit. What's rare is the combination this produces.
On one side of the market you have the platform builders: the owner can edit, but they're renting a template on a platform, paying every month, and the site looks like what it is. On the other side you have a developer hand-coding a bespoke site: it looks great and it's genuinely theirs, but the owner can't touch a word of it without going back to the developer and paying for an hour of someone's time.
Klaudius now gives the corner that's normally empty: a bespoke, owned, code-based site — the kind a developer builds, with a custom design made for that one business — that the owner can still edit themselves, with no monthly platform fee and nothing to maintain. They get the site a real developer would build and the self-service a platform would give them, without the rent and without the lock-in. That specific combination is the thing competitors don't put together, and it's the honest version of the pitch.
The money
Editability isn't a nice-to-have for the buyer. It's one of the questions standing between you and the sale. Look back at the real replies: "How can it be regularly edited?" "How do I add photos to each section?" These come up again and again, and for a meaningful share of owners the unspoken worry behind them is I don't want to be trapped paying someone forever every time my number changes. Until now the honest answer involved a caveat. Now the answer is simply yes — it comes with its own editor, and you run it yourself.
That changes two things about the economics.
First, it's a reason to charge more. A bespoke site is already a strong offer; a bespoke site the owner fully controls is a stronger one, and it's priced accordingly. You can fold the CMS into a higher one-off price, offer it as a paid add-on, or use it as the anchor of a small ongoing maintenance arrangement. It costs you one command and effectively nothing to run, and it visibly raises what the whole package is worth.
Second, it makes the deal stickier. An owner who's logging in and updating their own site is an owner who's using the thing they bought, which is the best protection against second thoughts and the best soil for a referral. The Watford builder who started this whole story has been managing his own portfolio for weeks; that's not a closed deal, it's an active relationship.
The shape of it is the same shape as everything else in Klaudius: the expensive, hard part — the engineering — was done once and turned into something repeatable, so that the marginal cost of delivering it to the next client rounds to zero. A custom CMS used to be a four-figure project. Now it's a command you run after a build, and a better answer to the question your buyers were already asking.
Team Klaudius