Static site, no CMS. How do you hand it to a client?

There is a kind of website that is a joy to build. It is a static site with a handful of pages, a stylesheet, maybe a form that posts to Netlify. No CMS, no database, no plugin updates. It builds in ten seconds and hosts for free. You ship it, the client is delighted, you send the invoice.

Then three weeks later the client wants a different photo on the about page.

This post is about that moment, because I have been on both sides of it and I do not think anyone talks honestly about the options. There are five, and every one of them costs something. In short:

1. You stay the editor. Free to set up, paid for in your attention at the worst times.
2. Add a Git-based CMS. Right for structured content; a rebuild for a hand-written site.
3. Move it to a page builder. The client gets control; you lose the stack.
4. Teach the client to use GitHub. Everyone tries it once.
5. Put an agent in front of the repository, with fences. Any change the files can express, as a pull request; new, and a few cents per change.

Here they are in full, in the order most people try them.

1. You stay the editor

The default. The client emails you, you make the change, you push. Sometimes you bill for it, usually you do not, because it feels absurd to invoice fifteen minutes.

Setup cost: zero. Ongoing cost: the highest of any option here, because it is paid in your attention at the worst possible times. The change is never urgent to you and always urgent to the client. You become a queue.

This works fine for a site that changes twice a year. It stops working the moment you have more than a few clients, or one client who is active. The tell is when you start dreading a particular name in your inbox.

Put numbers on it. A change takes fifteen minutes if you are at your desk with the repository open, and closer to forty if you are not: find the laptop, pull, find the file, make the change, check it, push, wait for the build, reply. Ten client sites at two requests a month each is twenty interruptions, somewhere between five and thirteen hours, none of it on the invoice. That is the real price of "free".

2. Add a Git-based CMS

This is the modern answer and it is a good one. Sitepins, Decap, Tina, Keystatic and a few others give the client a web editor that reads and writes files in the repository. Every save is a commit. You keep your stack, you keep version control, and the client gets a form.

I like this category and I would recommend it without hesitation for a site with structured content: a blog, a catalogue, a docs site, anything where the same shape repeats. The editor shows fields, the fields map onto front matter, and the client cannot break the layout because the layout is not in the form.

The costs are real, though, and they are mostly paid by you. You write the configuration that tells the CMS what the content looks like. The content has to be in a format the CMS understands, usually Markdown with front matter or JSON, which means the hand-written HTML site does not qualify without a rebuild. And every field you did not think of is a change request that comes back to you anyway. The client wants a second button in the hero. There is no field for that.

If you are building a new site and you know the content will be structured, pick one of these at the start. If you have an existing site with prose in HTML, it is a rebuild, and you should price it as one.

In time: a day to configure the CMS against a site whose content is already in Markdown with front matter, and something like a week to convert a hand-written HTML site into templates the CMS can drive, plus a session with the client to walk them through the editor. In money: most of these are free to self-host and ten to fifty dollars a month hosted, per site or per seat depending on the product.

3. Move it to a page builder

Webflow, Framer, Squarespace, or WordPress with a builder. The client gets full visual control. Some clients genuinely want this, and if yours does, this is the right answer and you should give it to them.

The cost is the site. You lose the stack you chose, the performance you got for free, the repository, and usually some of the design. You gain a monthly bill and a client who can, and will, restyle the footer. For a brochure site that is going to be redesigned in eighteen months anyway, that trade can be fine. For a site you were proud of, it hurts.

In time, a rebuild in a builder is a week or two for a six-page site if you do it properly, and it is a new project with a new invoice. In money, the builder plans that allow a custom domain and no badge run from around fifteen to forty dollars a month, for as long as the site exists. The client usually does not mind that part. The part they mind is discovering, six months on, that the version history is gone and the site cannot be moved.

4. Teach the client to use GitHub

I include this because everyone tries it once. You show them the web editor on github.com, the pencil icon, the commit button. They nod. Two weeks later they email you the change.

It is not that clients are incapable. It is that the interface is built for people who already know what a branch is, and every screen assumes it. The one time it works is when the client is a developer, at which point they did not need you for this.

The cost here is mostly the hour you spend on the walkthrough, and then the slow discovery that the walkthrough did not take. There is also a real risk: a client editing HTML in the GitHub web editor can break the page in ways that publish immediately, because there is no preview and no gate between the pencil icon and the live site. The cheapest option on paper is the only one that can take the site down.

5. Put an agent in front of the repository, with fences

This is the option I built, so discount what follows accordingly.

The client gets a chat box. They describe the change. A coding agent edits a copy of the files, a gate checks the edit against rules you wrote, the change becomes a pull request, the host builds a preview, and the client publishes from the preview. Nothing about the site changes: same repository, same host, same build. I have written up how it works in detail.

What this gets you that a CMS does not: the client can ask for anything the files can express, including the second button in the hero, and you did not have to predict it. It works on the hand-written HTML site as it stands, because the agent reads HTML the way it reads anything else. And every change is a pull request you can read.

What it costs: a small amount of money per change, a policy file you write once, a day of setup per site, and the acceptance that the agent will occasionally do the wrong thing and the client will have to say no and ask again. It is also new, which is a cost in itself. A CMS has years of other people finding its bugs. If you want the numbers, the hosted version is priced per website, falling as you add more, and the software is free to run yourself.

Which one

If the content is structured and edited often, a Git-based CMS. Build for it from the start.

If the client wants to design, a page builder. Give them the site and walk away.

If the site is a brochure, the content is prose in files, the changes are occasional and the client is not technical, an agent with fences. This is the gap I fell into with the first site I connected, and it is a common one: the site was too simple for a CMS and too finished for a rebuild.

If the site changes twice a year, stay the editor and stop feeling bad about it.

What I would not do is nothing. The moment you notice you are dreading a name in your inbox, the site has become a maintenance contract you did not sign, and every option above is cheaper than that.