How we chose a CMS for client websites

Every website we build reaches the same moment. The client wants to change a phone number, swap a photo, or add a post, and they should not have to email us to do it.

So we tested what is actually available. Not on a client’s site, on our own, which is the only place you can afford to find out that something breaks. We configured and ran four systems. We swapped this site’s CMS twice in two days.

Here is what we found, including the parts that made us change our minds.

The question that actually decides it

Most comparisons start with features. That turns out to be the wrong place to start.

The category we prefer is the git-based CMS, where your content lives in the same version-controlled repository as your code. It is worth caring about. You keep a full history of every change, the content is genuinely yours rather than sitting in someone else’s database, and there is no separate service to keep paying for.

The catch is authentication. Several of these tools expect the person editing to hold a developer account, because the editor runs in the browser and talks to the code repository directly. We put one client through that process: an account signup, an invitation that had to be accepted from an email, a two-factor question nobody could answer confidently, and an access token that only works if you pick exactly the right kind.

We reported that internally as proof the whole approach was too expensive for clients. When we went back and checked, two of those three problems were our own misreading of how GitHub’s token types work, not something GitHub did to us. The cost is real. It is smaller than we first said, and we would rather correct that than let a tidy story stand.

The options, side by side

Published facts, checked in August 2026, in US dollars.

One caveat that matters: we have not bought any of these. Everything here comes from free tiers, trial licences and public pricing pages. Treat it as a starting point for your own research rather than a quote.

Product	Editor needs a developer account	Content stays in your repository	Price when we checked
Sveltia CMS	Yes, a GitHub account	Yes	Free, open source
CloudCannon	No	Yes	From $10/month on the partner plan, $55/month standard
TinaCMS	No	Yes	Free for one project, then $24/month
Keystatic	No, using Keystatic Cloud	Yes	Free for up to three users, then $10/month
Decap CMS	Yes, a GitHub account	Yes	Free, open source

Everything below this line is our own experience of running them, which is not something you will find on anybody’s website.

Product	What worked	What we hit
Sveltia CMS	Fast editor. Resizes and converts images in the browser before they are ever saved. Drafts go to a preview build that the editor can open, and the site only republishes when they publish. Left our content exactly as it found it.	The editor needs a GitHub account, and that account can see the whole repository. Largely a single maintainer, shipping most days.
CloudCannon	The best client access of anything we ran. A password and a link, no accounts to create. Real page previews. A company behind it. Edits left neighbouring fields untouched.	More to learn for someone who edits twice a year. Publishing workflows sit on the higher plans and we have an open question with them about exactly where that line falls. Reformatted markdown tables on save.
Keystatic	Solved the account problem through its hosted option, and the Astro integration is first-class.	Rewrote markdown tables into a syntax the page printed literally. Regenerated the filename from the post title, so saving an existing post changed its web address. We could not find a way to turn that off.
Decap CMS	The long-standing default, and the file format everything else reads.	Its usual login method depends on a Netlify service that is now deprecated, so new sites cannot start there. That is what set this whole exercise going.
TinaCMS	Not tested. It solves the same account problem, and it has the largest development team of anything on this list.	We did not trial it. At $24 a month per project it was the most expensive way to answer a question we could answer for nothing, so it lost its slot. That is a scheduling decision, not a verdict.

Five things we learned by testing rather than reading

Documentation will not tell you what breaks. Every one of these products has a polished website and a features page. None of them mention what happens to a table you had already written, which brings us to the next point.

Tables are where these tools differ most, and nobody talks about it. We had one post containing a comparison table. Keystatic converted it to a template syntax that the page then printed on screen as raw code. CloudCannon put a backslash in front of every vertical bar and folded the whole table onto one line. Sveltia left it completely alone, in both markdown and HTML. So our rule now is to write tables as HTML, because HTML came through all three unchanged. The two tables you just read are HTML for exactly that reason. The point is not that one product is careless. It is that your content has to survive changing your mind, and ours changed twice in a week.

A content edit can break a build, and the person who made the edit cannot tell. Leave an optional field blank and some systems write an empty value where the site expects a date. Upload a file with a # in the name and it can fail the build merely by being in the repository. That one cost us seven deploys in a row on another site, and the fix was not to teach the client to name files better. It was to make the site tolerate whatever a CMS actually writes, and to sanitise the filename in the browser before it is ever saved.

Saving is not free. Watch anyone use one of these tools and you will see them save constantly, which is exactly what they should do. On a simple setup every one of those saves rebuilds and republishes the entire website. The better arrangement puts drafts on a preview the editor can look at, and only touches the live site when they choose to publish.

Project health is measurable, so measure it. Rather than guess which of these is well supported, we counted ninety days of public activity on each. Sveltia was shipping releases almost daily and closing more support issues than it received. One had gone quiet for three and a half months earlier in the year while its backlog grew. TinaCMS had a genuine team rather than one very fast individual, which is a real advantage over the life of a site even though we did not test the product. On their websites they all look equally alive.

Where we landed

There is no single answer. That is the honest conclusion rather than a hedge, because the right choice depends on who is editing.

Our own sites run Sveltia, and this one is the second we moved across. It is free, it is quick, it optimises images before they reach the repository, and an editor can see a preview of the actual page before anything goes live. The cost is the GitHub account, and that account can read and write the whole repository. For a technical editor that is a fair trade.

For a client who should never see a repository, CloudCannon is the one we have run end to end, and its client access is genuinely the simplest thing we tested. A password and a link is the entire handover.

TinaCMS deserves a place on your shortlist. It answers the same account question and it has the deepest team behind it. We have not run it, so we will not pretend to have an opinion on how it feels to use.

The foundation is the part that does not change. Your content stays in version control, the site stays fast because it is still built as static files, and moving between these tools is a decision you can revisit. We know that last part is true because we did it, twice, on the page you are reading.

Want this on your site?

If you have a website you cannot update without calling someone, or you are planning a build and want your team editing it from day one, we can help. We do this on our own site first, which is how we know where these tools break.

Tell us what you are working with and we will tell you honestly what would suit it.