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. On a willing client’s site, and 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 GitHub 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 long term licenses for any of these. Everything here comes from 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 any product 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. Our favourite.	The editor needs a GitHub account, and that account can see the whole repository. Mostly maintained by a single developer, shipping most days, actively supported.
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 (draft/review before publish) sit on the higher plans. Reformatted markdown tables on save.
Keystatic	Solved the account problem through its hosted option, and the Astro integration is first-class.	Basic editor that 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. Probably this could be switched off, but we found the editor too basic to bother pursuing.
Decap (Netlify) CMS	The long-standing default, and the file format natively Astro.	Its usual login method depends on a Netlify service that is now deprecated, so new sites cannot start there. It's in maintenance mode only with it's authentication method now deprecated. That is what set this whole exercise going.
TinaCMS	Not actively tested, evaluated only. It will solve the same account problem as CloudCannon, and it has the largest development team of anything on this list, so a promising contender.	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 with Sveltia, so it lost its slot. That was 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 above 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. Not all of these products provide that on the free plan or lower tiers.

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. KeyStatic 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 and your budget.

Our own sites now run on Sveltia. 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 via Netlify branch previews. The cost is the GitHub account, and that account has access to read and write the whole repository. For a technical editor that is a fair trade, but it may not be for everyone.

For a client who never needs repository access, 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, but worth consideration if you have the budget.

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 in two days, on the page you are reading now.

Want help 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 did this on our own site first, which is how we know where these tools excel and where they break.

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