Who actually owns your client's content?
Every CMS answers this question, most of them quietly. The answer decides what happens when your client stops paying, or stops working with you.
Chris Good
Founder, Boosh Digital
Ask a web agency where their clients’ content lives and you will usually get an answer about a platform rather than about a place. That is the whole problem in one sentence.
Three answers, and what each one costs
In the vendor’s database. Sanity, Contentful, most of the hosted CMSs. The words live in someone else’s service and the site fetches them at build or at runtime. This works well and the editing experience is genuinely good. The cost arrives later: the site cannot build without the service, and getting the content out means an export you have to write.
In a database you run. Payload, Strapi, WordPress. Nobody else holds the content, which is better. But something has to be alive for the site to work, and something being alive is the part that gets forgotten in year three when nobody remembers which server it was on.
In the repository. Markdown files sitting next to the code. The site reads them the way it reads anything else. There is nothing to export, because the content is already the site.
The question that decides it
Not “which is best”. Ask instead: if this tool disappeared tomorrow, what would the client still have?
With content in files, the answer is everything. The site builds with
astro build, the words are readable in any text editor, and the history of who
changed what is the git history you already had.
The objection, and it is a fair one
Files in a repository sound great until you picture the client meeting a branch. That is the actual difficulty, and it is why most git-based tools end up aimed at developers.
It is solvable, but only by accepting a constraint: the page becomes a document, and code renders it. No CMS edits arbitrary page source, not one of them, and not for want of trying. A page’s source is open-ended, and to edit it safely you would have to model everything a developer might write.
So the client arranges sections you built, in an order they choose, with the fields you defined. They never meet a filename. The developer keeps the parts that need judgement, and the client gets the parts that need doing weekly.
What to actually do
If you are choosing now, work backwards from the handover rather than forwards from the demo:
- Where does the client’s writing physically end up?
- What still works if you stop being involved?
- How many times do you describe the shape of the content: once, or once per tool?
- What does the client pay, monthly, forever, to keep editing their own words?
The last one is the conversation nobody enjoys having in year two. It is much easier if the answer is nothing.
If you are picking a CMS for an Astro project right now, I compared the realistic options in more depth over on chrisgood.online in which CMS to use with Astro websites, and BooshCMS is what came out of that thinking. The documentation covers what a project has to look like for it to work.
Chris Good
Founder, Boosh Digital
Chris builds the Boosh apps and runs the studio they came out of. Everything here is written from doing the work rather than reading about it. The apps exist because the tools he needed either did not exist or wanted a monthly fee for the privilege.
