Choosing a CMS for a client project: the questions to ask before the demo
Feature comparisons are the least useful way to pick a CMS for client work. Twelve questions that predict how a tool behaves in year two, and what a good answer sounds like.
Feature tables are a bad way to choose a CMS for client work. Every serious tool has rich text, media, roles and an API, so the table comes out even and you pick on price or on whichever demo was slickest.
What actually differentiates these tools is how they behave in year two: when the client’s colleague has left, when the model needs changing, when a build fails on a Friday, when you have fifteen sites instead of one.
Here are the twelve questions that predict that, and what a good answer sounds like. They are worth asking before the demo, because a demo is designed to answer different questions.
Money
1. What does this cost at my actual site count?
Not per site: total, at fifteen or twenty, with two editors each and two languages each. Vendors price for a company with one website, and the arithmetic changes character when you multiply.
A good answer is a number you can compute yourself from the pricing page. A bad one requires a sales call.
2. What does an extra editor cost?
If the answer is not zero, model it at forty editors, because an agency’s editor count grows with every client. Per-seat pricing pushes you toward sharing one login between several people, which destroys your audit trail exactly when you need it.
3. What does an extra language cost?
In Europe this matters more than people expect. Some vendors charge twenty dollars a month per additional locale, per site, forever. A trilingual brochure site can cost more in locale add-ons than an entire fleet subscription elsewhere.
The client
4. What does my client need in order to log in?
An email address is the good answer. A GitHub account is a support call, every time, forever. Anything requiring a developer platform identity will produce confusion at the exact moment the client is already frustrated.
5. How many screens can they reach that they should not?
Every setting a client can see is a question they can ask you later, and a thing they can break while you are on holiday. Ask to see the editor’s view specifically, not the admin’s.
6. What do they see after they click Publish?
The single most revealing question in this list. If the answer is a confirmation meaning “saved”, the client will believe their change is live when it may not be, and they will find out from a customer. If the answer names a state and a time, someone has done the unglamorous work of tracking the deployment.
The model
7. Can the content model live in version control?
A model clicked together in an admin cannot be diffed, reviewed, branched or copied to site sixteen. A model in a file can. For one site this is aesthetics; across a fleet it is the difference between an afternoon and a week per new project.
8. What happens when I rename a field with content in it?
Ask them to show you. The right behaviour is to detect the destructive change and refuse to apply it silently. “The old data is gone” is disqualifying, and you will not discover it until it has happened to a client.
9. Show me the export, now.
Not a description: the actual command, on the free tier, and let us look at what comes out. Markdown and JSON in a shape your next tool reads is an exit. A proprietary dump is not.
This question matters more the larger your fleet gets, because migrating twenty sites is a project nobody will finance, which means when the price rises you will pay it.
The operations
10. What happens if I request another tenant’s resource by id?
The right answer is 404, everywhere. A 403 confirms the resource exists, which across a client fleet means your client can discover who else you work with.
11. Where does the build read content from, and what happens during an outage?
If the build calls the vendor’s live API, their bad afternoon is your failed deploy. If it reads an immutable snapshot from a CDN, an outage is irrelevant to your client’s site. Ask whether they have actually tested it, rather than whether it should work.
12. Who is behind this, and what happens if they stop?
For open source: how many maintainers, when was the last release, is there a paid tier funding it. For hosted: how are they funded, how long have they existed, what does the export look like. Neither answer is disqualifying on its own. Not knowing is.
Three questions that are not worth asking
Balance matters, so here are three things people evaluate that predict very little.
“Does it have a visual editor?” It sounds decisive and usually is not, because the question underneath is whether your client composes pages or fills in fields. A client who changes a price and a photo four times a year gets no value from a visual editor and will pay for it monthly. A marketing team that assembles landing pages gets enormous value. Establish which one you have before you weight this at all.
“How many integrations does it have?” A long integration list is a marketing artefact. For a brochure site you need exactly one: your framework. A CMS with two hundred integrations and a mediocre Astro loader is worse than one with a single excellent loader.
“Is it open source?” A genuinely important question for some clients and irrelevant for most, and it is frequently used as a proxy for “can I trust this”, which it is not. Open source protects you against a vendor disappearing only if you can realistically run it yourself, which for a twenty-site fleet means operating twenty instances. Ask about the export instead: it is the thing that actually protects you, and it applies to both open and closed products.
What a good answer sounds like
Across all twelve, the pattern in a trustworthy answer is the same: specific, checkable, and willing to name a limit.
“Publishing takes one to three minutes because there is a build, and the interface shows the progress” is a good answer. “Publishing is instant” is a bad one for a static site, because it is not true and you will discover how.
Be suspicious of any vendor, including us, that answers all twelve without conceding anything. Every tool here is bad at something, and the ones that will not say what are the ones that will surprise you.
Our own answers, including the awkward ones
Since this is our blog, here are ours, briefly.
Cost is per site, unlimited editors and locales from the first paid plan. Clients sign in with an email address. There is no settings screen for editors. After Publish they see progress ending at live at a specific time. The model is TypeScript in your repository. Destructive schema changes are detected and refused rather than applied. Export is one command, on every plan including free, producing markdown and JSON in content-collections format. Cross-tenant requests return 404. Builds read an immutable snapshot from a CDN, and we test that by switching our API off.
And the limits, because the section above demands them: publishing takes one to three minutes. There is no visual page builder. There is no content API at request time. There is no self-hosted version. We support Astro and nothing else. We are a small team on a young product, which is a real risk you should price in, and the reason the export question is one you should ask us hardest.
The demo itself, and how to run it
If a tool survives the questions, the demo is worth doing properly rather than being shown a script.
Bring your own project. Ask to model one real collection from a real client site, with its real fields and its awkward one. Every CMS demos beautifully on a blog post with a title and a body. The interesting behaviour appears on the field that does not fit.
Ask for the editor’s view, not the admin’s. Vendors demo the admin interface, which is the one you will use twice a month. Your client lives in the editor view, and on several products it is visibly less considered.
Break something on purpose. Publish with a required field empty. Upload a HEIC photo from an iPhone. Delete an image that a live page uses. The error messages you get are a better predictor of year two than any feature.
Watch the clock during publishing. Time it, and ask what the editor sees while they wait.
Half an hour spent this way tells you more than a week of reading documentation, and it is the only part of the evaluation that cannot be done from the pricing page.
How to use this list
Print it, or keep it in a note. Ask questions 1, 6 and 9 before you book a demo, because they eliminate most options in ten minutes and none of them require anyone’s time but your own.
The remaining nine are worth going through with a real project in mind rather than in the abstract. And if you want the per-vendor version of this, the comparisons go through Contentful, Strapi, Sanity, Storyblok, Directus and the git-based family, each with the cases where they are the better choice.