Choosing a CMS for a content team starts with counting five things about the team, not with comparing features. How many people publish. How technical the least technical of them is. How many posts go out in a week. How many approvals stand between a finished draft and a live post. And how many people could keep the system running if whoever set it up left tomorrow. Those five numbers narrow the field faster than any feature table, because a feature list tells you what a platform can do and your team profile tells you what will actually get done.
A note on where this is coming from. Search this question and nearly every result is published by a CMS vendor or by an agency that implements one. Much of that advice is competent, and all of it is written by someone with a preferred answer. Kahuk sells no CMS, hosts none, implements none, and takes no referral fee from any platform. This article also states no prices, deliberately: vendor pricing in this category changes without notice, and a stale figure is worse than none.
Where the standard advice stops
The usual guidance is not wrong. Consider your publishing volume, know who will use the platform, check roles and permissions, look at the editor, run a hands-on trial. You have probably read that three times already.
Here is where it stops. Those guides tell you to consider your team, then return immediately to describing platform capabilities, because capabilities are what the publisher of the guide sells. Nobody hands you a way to turn your team into an answer. That conversion is the whole job.
Choosing a CMS for a content team: the five numbers
Count these before you open a single vendor page. Each is countable in about twenty minutes and none requires you to know anything about software.
| # | The number | How to count it | What it decides |
|---|---|---|---|
| 1 | Publishers | Everyone who puts content in, including occasional and external people | How much the permissions model matters |
| 2 | The technical floor | The comfort level of your least technical publisher, not the average | Whether whole families of platform are disqualified |
| 3 | Cadence | Posts per week at your real rate, not your ambition | How much any single point of friction costs you |
| 4 | Review depth | Approvals between a finished draft and a live post | Whether you need workflow states or a draft toggle |
| 5 | Bus factor | People who could keep it running alone | How much operational risk the choice carries |
1. Publishers: count the occasional ones
What matters is not headcount, it is how many distinct people touch the publish button in a normal quarter. Teams answer “three” and then remember the freelancer who files twice a month, the colleague in another department who owns two pages, and the founder who posts announcements.
Each of those people needs an account, a permission level, and somewhere to be stopped from doing damage. On some platforms that is a dropdown. On others it is a configuration project. If your honest count is one or two, permissions are close to irrelevant and you should not pay for them.
2. The technical floor governs, not the average
This is the most misread input in the decision, and the reason so many CMS choices are technically excellent and practically abandoned.
Your usable options are set by the least technical publisher, because that person’s difficulty becomes somebody else’s support work and eventually becomes a workaround where they email a document to someone who pastes it in. Averages hide this. A team of one developer and three writers has a high average and a low floor, and the floor decides.
The test takes fifteen minutes: have that person publish one real post, unaided, while you watch and say nothing. Where they hesitate is your answer, and no comparison page can give it to you, because no vendor documents the moment their user gets stuck.
An entire architectural family lives or dies here. Git-based systems, where publishing means a commit and a build, are good software that place the technical floor high by design, and several of them put a friendly editing layer over the repository specifically to lower it again. That is the question to ask before ruling the family in or out, and it is the one that decides our comparison of TinaCMS, Keystatic and Decap.
3. Cadence: friction, multiplied
A point of friction costing two minutes is trivial at two posts a month and expensive at twenty posts a week. Cadence is the multiplier on every other flaw, which is why a team publishing rarely tolerates a platform a busy team cannot.
It cuts the other way too. High cadence justifies investment in the publishing path itself: scheduling, bulk operations, reusable blocks, templated post types. At three posts a month, all of that is cost with no return.
Count your real rate over the last three months, not the rate you plan to reach once the new system fixes everything. It will not, and that plan is how teams end up operating a platform sized for a publication they do not have.
4. Review depth: the number nobody writes down
Multiply cadence by approval stages and you get the handoffs your system carries every week. Ten posts a week through a three-stage review is thirty handoffs. If the CMS has no state between “draft” and “published”, all thirty happen in chat messages and email, and the CMS is not managing your workflow at all. It is storing the result of one that happens elsewhere.
Write the actual chain down: writer finishes, editor edits, a subject expert checks the facts, someone schedules it. Then ask of each stage whether it needs to see the post in place with images and formatting, whether it needs to comment inside the document, and whether it must be blocked from publishing before its turn.
One editor and a shared understanding needs a draft toggle and nothing more. A compliance review needs enforced states, and buying a platform without them means rebuilding the review in a spreadsheet.
5. Bus factor: what happens when the one developer leaves
Ask it plainly. If the person who set this up left tomorrow, what stops?
List every task on the publishing path that exactly one person can do: deploying a change, restoring a backup, adding a field to a content type, fixing a failed build. If any of them sits between a finished draft and a live post, that person’s departure does not slow development down, it stops publishing.
This risk belongs to the arrangement, not the platform, and vendors rarely raise it because their answer is to hire an agency. Two dull things reduce it: choose a platform with a large pool of people who know it, and keep the setup documented and reproducible by someone else. A widely used platform you can hire for is safer than a better one only your contractor understands.
The same five questions, four different answers
This is what makes it a framework rather than a checklist. Four real team shapes go through the identical five questions and land in four different places, none of them reachable by comparing features.
| Team profile | The five numbers | What it points to | What usually goes wrong |
|---|---|---|---|
| Solo operator or a pair, both comfortable with software | 1-2 publishers, high floor, 1-3 posts a week, no formal review, bus factor 1 | Almost anything works, so optimize for low maintenance and a clean export. A Git-based setup is genuinely viable | Buying for a team that does not exist, then paying for it weekly in admin time |
| Small editorial team with rotating freelancers | 4-8 publishers, low floor, 5-15 posts a week, one editor reviews, no developer | Browser-based editing, real roles, a review state, no build step on the publishing path | Adopting whatever the one technical contractor prefers, then finding freelancers cannot file |
| Marketing team inside a company | 2-5 publishers, mixed floor, 2-6 posts a month, three approvals, a developer on another team’s backlog | Enforced workflow states, scheduling, previews, and no developer ticket for routine pages | Underestimating review depth, then bottlenecking on approvals anyway |
| Product or documentation team | 3-6 publishers, all technical, irregular cadence, review already in pull requests, bus factor 2-3 | Git-based or headless is the honest fit, because the review they already run is the platform’s native model | Adding a second review system beside the one everyone already uses |
Read rows two and four together. Same size, similar output, and the right answer for one is close to the worst answer for the other. What separated them was the technical floor and where review already happens. Row two is also the case where an all-or-nothing framing does the most damage, because there is a middle option: keep the editing experience your writers already know and replace only the front end, which is what headless WordPress means in practice. It raises the technical floor for developers rather than for writers, and that is exactly the trade row two can afford.
For many teams, the answer is the CMS you already have
Vendor guides rarely reach this conclusion and it is frequently the correct one.
The five numbers do two jobs. They describe what a new platform would need, and they price what a move would cost, because the people who publish are the same people who must relearn everything, verify the archive, and absorb whatever the import mangles. A team at the edge of its capacity can least afford that and is most tempted by it, because the pressure that makes a platform feel wrong is usually workload rather than software.
So run the profile against your current system first and mark which of the five it genuinely fails. If it fails none and the complaint is that the editor feels dated, that is an aesthetic problem and a migration will not fix it. If your writers cannot clear the technical floor, or your bus factor is one, or the review your organization requires cannot be represented at all, that is structural and worth moving for. It also helps to know a candidate move is reversible before you commit to it: the WordPress and Ghost pairing is unusually well documented in both directions, going from WordPress to Ghost and back again from Ghost to WordPress, which makes it a cheaper bet than a platform with a one-way door.
Whichever way you go, the switching cost is not hypothetical. What actually breaks during a CMS migration covers the parts that survive badly, and the CMS migration guide covers the sequence and the order to do it in.
What this framework will not tell you
Nothing about the front end. Design and performance are a separate decision, and on some platforms a separate decision from this one, on others the same one.
It does not survive a hard requirement. Multiple languages, multiple sites, ecommerce, a regulated approval trail, an accessibility standard you must meet: any of these can eliminate most of the field alone and outranks everything above.
It prices nothing, for the reason given at the top. When you reach cost, find what scales in the pricing model, usually traffic, storage, API calls, users or seats, and estimate month twelve rather than month one.
It cannot tell you whether a platform will exist in five years. Nobody can. What partly covers you is a complete, documented export you can run yourself, checked before you move in rather than when you want to leave.
Running this in one afternoon
- Write the five numbers on one page: publishers, technical floor, cadence, review depth, bus factor.
- Score your current system against each. Mark real failures, not irritations.
- If nothing structural fails, stop here. That is a valid and cheap outcome.
- If something fails, those items are your requirements. Ignore every feature that is not one of them.
- Shortlist three, then have your least technical publisher file one real post on each while you watch in silence.
- Ask each shortlisted platform how you would export everything and leave, then verify the answer instead of accepting it.
The platform you want is the boring one your team can operate without help, and the archive you build on it will be worth more than any feature you gave up to get it.
FAQ
How do I choose a CMS for a content team without comparing every platform?
Start with the team, not the market. Count five things: how many people publish, how technical the least technical of them is, posts per week, approval stages per post, and how many people could run the system alone. Those five become your requirements, and requirements eliminate most of the field before you read a feature list.
Does the size of my team decide which CMS I need?
Less than you would expect. Two teams of the same size can need opposite systems, because what separates them is the technical comfort of the least technical publisher and where their review already happens. A five-person team of developers and a five-person team of freelance writers are not the same buyer.
How many people should be able to publish in a CMS?
There is no correct number, but count yours honestly and include the occasional and external people, because they are who permissions exist for. If the real count is one or two, do not pay for a permissions model. If it includes people outside your organization, test guest access early, since it is often the weakest part of a platform.
What happens if the developer who set up our CMS leaves?
That depends on the arrangement more than the software. List every task between a finished draft and a live post that only one person can do, such as deploying, restoring a backup, or adding a field. If any sits on that path, publishing stops when that person does. A widely used platform with a documented, reproducible setup is the practical mitigation.
Should we switch CMS if the team is unhappy with the current one?
Only after separating the platform from the workload. Score your current system against the same five questions and mark genuine structural failures: a technical floor your writers cannot clear, a required review the system cannot represent, a bus factor of one. Dissatisfaction without a structural failure usually travels with the team to the next platform.
Written August 2026. This article describes categories of platform and states no vendor pricing, because pricing in this category changes without notice; verify specifics against each vendor’s own current documentation. For scale, the Jamstack headless CMS directory listed roughly 165 platforms when we checked it on July 28, 2026. No platform is recommended here and no referral fee is taken from any vendor. Due for review every 90 days.
