How to let a client edit a static site without handing over the repo
Five ways to give a non-technical client edit rights on a static site, what each one really costs in support, and the two questions that decide which one fits.
You built a fast static site. It deploys to a CDN, costs almost nothing to host, and scores well on every metric anyone measures. Then the client asks how they change a price, and you realise the honest answer is “you email me”.
That answer holds for about three months. After that it becomes a recurring interruption for you and a source of quiet frustration for them, and one of you eventually does something about it.
Here are the five real options, with what each actually costs.
Option 1: they email you
Let us take it seriously, because it is the right answer more often than developers admit.
If the content changes twice a year and you already bill a maintenance retainer, a five-minute edit is inside what you are being paid for. Adding a CMS means a subscription, an onboarding session, and a tool the client uses so rarely they forget how it works between visits.
Where it fails: the moment the frequency crosses roughly once a month. At that point the interruptions cost you more in context switching than any subscription, and the client starts feeling like a nuisance for asking. That feeling is the real damage: it is where “our web person is hard to reach” comes from, and it ends relationships.
Option 2: give them the repository
The CMS-free version: teach the client markdown, give them a GitHub account, let them edit files in the web interface.
I have seen this work exactly once, with a client who happened to be an engineer. For everyone else it fails at the first merge conflict, or at the two-factor setup, or at the moment they accidentally edit astro.config.mjs because it was in the file list.
Where it fails: almost always. The failure mode is not that they break the site, though that happens. It is that they stop touching it out of fear, and you are back to option 1 while also paying for the setup.
Option 3: a git-based CMS
Decap, Sveltia, Keystatic, Tina. A form-based interface that commits markdown into your repository. Free, no server, content stays in Git.
This is a real improvement: the client sees fields instead of files, and cannot edit your config by accident. What has not gone away is the account. To authorise the CMS to write to the repo, your client needs an identity on GitHub or GitLab, and has to grant an application write access to a code repository. For a developer that is nothing. For a florist it is a genuinely confusing screen.
The other thing that has not gone away is you. Each site is a configuration file you maintain by hand, each major version brings breaking changes, and images go into Git and stay there.
Where it fails: across a fleet. One site is fine. Twenty sites is a permanent maintenance tax and a category of support call you will take forever. The detailed comparison covers where it still wins.
Option 4: a headless CMS
Contentful, Sanity, Storyblok, Strapi, Prismic. A hosted content API, a proper editing interface, no repository access for anyone.
This solves the client-facing problem properly. The editing experience is good, media is handled, and nobody sees GitHub.
It introduces two new ones. Price, which is per project or per seat and adds up brutally across a fleet: as surveyed on 8 August 2026, Contentful jumps from free to €300 a month with nothing in between, Sanity charges $15 per seat, Storyblok adds $20 a month for each extra locale. And the last mile: these tools publish into their own API and, at best, fire a webhook. Whether your site rebuilt, whether the build failed, whether the page the client just edited is actually being served, is not their concern. Your client clicks Publish and gets a confirmation that means “saved in our database”, which is not what they think it means.
Where it fails: when the number of sites multiplies the price, and when nobody notices a failed build until a customer does.
Option 5: a CMS that finishes the job
The fifth option is the one we built, so read the following knowing who is writing it.
The premise is that publishing should mean the page is live, not that a row was written. Concretely, when the editor clicks Publish:
- The current content is frozen into an immutable snapshot and pushed to a CDN.
- The CMS triggers the rebuild at whatever host the site already lives on: Vercel, Netlify, Cloudflare Pages, GitHub Actions, or a plain server.
- It follows the deployment and shows the editor the real state, ending at “live at 2:32 pm”.
The consequences that matter beyond the nice message: because the snapshot is on a CDN rather than inside the API, a build succeeds even while the CMS is down. Your client’s site has no runtime dependency on us at all. We test that deliberately by switching the API off and checking a deployment still goes through.
The client signs in with an email address. No developer platform, no consent screen, no repository.
The two questions that decide
Everything above collapses into two questions.
How often does the content change?
Under six times a year, do not buy a CMS. Handle it in your retainer and spend the money elsewhere. Between monthly and weekly, a CMS pays for itself in interruptions avoided. Daily or more, you should be asking whether a static site is still the right shape.
How many sites are you responsible for?
One site changes the maths completely. On one site, a git-based CMS is free and the maintenance is trivial, or a headless free tier is generous enough to never pay. It is the fleet that breaks things: per-project pricing multiplies, hand-maintained configurations multiply, and support calls multiply.
| Frequency | One site | A fleet |
|---|---|---|
| Twice a year | Email you | Email you |
| Monthly | Git-based CMS | A per-site hosted CMS |
| Weekly | Any CMS | A per-site hosted CMS |
| Daily | Reconsider static | Reconsider static |
The part nobody plans for: the handover
Whichever option you pick, there is a moment where you show the client the tool, and that moment decides whether any of this was worth it.
Two things go wrong reliably.
You demo the admin, not their job. Developers show the interface: here are the collections, here is the media library, here is the settings screen. The client nods politely and remembers none of it, because none of it was framed around a thing they actually want to do. What works instead is doing their real task in front of them: “you want to change the price of a service, here is exactly that, three clicks.” Then hand them the mouse and let them do it once while you watch.
You give them too many rights. If the client can edit the navigation, restructure collections or change site settings, one of them eventually will, at a moment when you are on holiday. Give an editor the fields they need and nothing else. This is not distrust, it is the same reason we do not give ourselves production database access by default.
A practical measure worth applying: if a client is stuck for more than ten minutes on a routine edit, that is a bug in your setup, not a training problem. Either the field is badly labelled, the flow has a step that should not exist, or the tool is wrong for them. Every time we have investigated one of those ten-minute moments, the fix was on our side.
What we deliberately do not do
Since this is our blog, the limits belong here rather than in a footnote.
Publishing takes a build, usually one to three minutes. If your client needs a change visible in ten seconds, we are the wrong shape and server rendering is right.
There is no visual page builder. The developer defines fields, the client fills them. If your client composes landing pages from blocks and wants to see the layout as they type, Storyblok does that better than we ever will.
Astro only. Not Next, not Nuxt, not Hugo. This is a deliberate bet: one framework, a native typed loader, compatibility guaranteed within fourteen days of every major release. If your stack is elsewhere, we are not an option.
We are a hosted service. There is no self-hosted Menestrel. If your client requires the content to live on their infrastructure, a git-based CMS or Strapi is your answer.
Where to start
If you want to see the editing side before committing anything, the free plan covers one complete site with two languages and two editors, with no card. npm create menestrel@latest puts a working project on its feet in one command, and menestrel import reads an existing Astro site’s content collections, images included, if you already have one to move.
If you would rather see how we stack up against the tool you are already using, the comparisons go through Contentful, Strapi, Sanity, Storyblok, Directus and the git-based family one by one, including the cases where they are the better choice.