It started with a Watford builder, mid-deal, in one of the threads from our post on what to do when a business replies. He 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. We built him one: designed around his site, hardened, and deployed to /admin behind a password he could remember. He has been managing his own portfolio ever since.
That first editor was a bespoke build, engineered for one site. Delivering one is a project. Delivering one with every site you sell, reliably, with no broken editor ever reaching a client, is an engineering problem of a different order.
And the request kept coming. "How do I add photos?" "How can it be regularly edited?" Ask enough owners and you find that most of what stands between you and a signature is some version of can I change this myself once it's mine?
So we built it into the product. One command now adds a complete, bespoke content management system to any site Klaudius builds. This post covers what it does, how it 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.
That split is the part that can't be improvised, because the two halves want opposite things. The editable fields should be different on every site. The plumbing should never be. Ask an AI to build a CMS from scratch each time and it reinvents both — a different auth scheme, a different storage layout, a different set of things that quietly break on the third edit. You find those the hard way: in production, on a paying client's live site, weeks after you handed it over.
The plumbing in Klaudius has already been through that. It was hardened on the real businesses we built and sold sites to ourselves, and every break it turned up is already fixed in the copy that installs. So the editor your client logs into is genuinely theirs — their sections, their fields, their photos, worked out from their own site. What's underneath it isn't new. It's the same machinery that has been running on other people's websites for months, and it's the reason a bespoke editor can be a one-shot instead of a gamble.
So the outcome is the same every time even though no two editors are: a working editor, live, with a password in your hand. What's been engineered out of "build them a CMS" isn't the craft. It's the risk.
/cms acme-roofing — the AI reads the finished site, works out what should be editable, builds the editor, wires up the storage, sets a password and redeploys, then hands you the password and a note you can forward straight to the client. It ships with every Klaudius licence, alongside the site-building pipeline itself. Learn more about Klaudius →
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.
Like Rescue mode, the booking systems and everything else since launch: if you own a licence, you already own this. That's the deal, and it doesn't change.
Team Klaudius