The CMS decision matrix we actually use with clients

CMS recommendations tend to start from technology: WordPress is popular, Webflow is visual, a headless CMS is modern. We start from a different question entirely: who is actually going to log in and use this day to day, how often, and how technical are they. The right CMS for a given client falls out of those answers far more reliably than it falls out of a general technology preference.

This distinction matters because most CMS conversations happen between the people least likely to actually use the finished platform day to day, a founder or a marketing lead making a strategic decision on behalf of a content editor who isn't in the room. We make a point of including that editor's actual working reality in the decision, not just the decision-maker's stated preference.

A marketing team publishing daily needs a fast, forgiving editing experience, regardless of platform. A team updating content quarterly can tolerate a steeper interface in exchange for other benefits, since the friction cost is paid rarely. We map every CMS candidate against both axes for the specific client, not against a generic ranking of CMS platforms.

We've seen both mismatches play out badly: a team publishing daily stuck with a platform that requires a developer to make routine changes, and a team publishing quarterly paying for a premium, high-friction platform that solves a speed problem they never actually had. Getting the mapping right the first time avoids both of those expensive-to-reverse outcomes.

A headless CMS (Sanity, Contentful, and similar) genuinely shines when content needs to power multiple different frontends, a website and a mobile app, for instance, or when a highly custom frontend architecture already exists. For a single website with a non-technical content team, it often adds complexity (a separate frontend to build and maintain) without a corresponding benefit, compared to a more integrated platform.

The appeal of a headless CMS is real and well-earned in the right context, it's simply a narrower context than most clients asking for one actually have. We ask directly whether a second frontend consuming the same content is a genuine near-term plan or a speculative someday possibility, since only the former justifies the added complexity today.

A short session watching the actual person who'll manage content use the current system surfaces real friction points a requirements conversation alone misses. More than once, a client's stated preference for a modern, code-heavy solution turned out to be the wrong fit once we saw who was actually going to be the one logging in every week to make updates.

These sessions run about thirty minutes and consistently surface more useful information than a much longer stakeholder interview, because watching someone actually struggle with a specific step reveals a concrete requirement in a way a general conversation about preferences rarely does. We treat this as a mandatory step for any CMS recommendation, not an optional nicety.

Beyond picking the right platform going forward, we always price out what it actually costs to move existing content off the current system, since that cost sometimes changes the recommendation entirely. A technically superior platform that requires months of manual content migration can be the wrong practical choice compared to a good-enough platform with a clean, mostly automated import path.

We ask for a sample export from the current system early specifically to test the migration path with real data rather than a vendor's marketing claims about import compatibility, since the gap between a platform's advertised migration support and its actual real-world behavior with a specific client's messy, years-old content structure is often larger than either party expects going in.

A CMS's monthly license fee is often the smallest part of its real cost. Training time for the content team, the cost of any developer support needed for ongoing maintenance, and the cost of eventually migrating away if the platform stops fitting the business all belong in an honest comparison, and we walk through all three explicitly rather than letting a comparison collapse down to license price alone.

Clients consistently find this framing useful even when it doesn't change the final recommendation, since it gives them language to justify the decision internally to stakeholders who might otherwise fixate on the sticker price of a chosen platform versus a cheaper-looking alternative that would have cost more in the categories that don't show up on an invoice.

A CMS chosen well for one content team can stop being the right fit after real staff turnover, since the platform was matched to a specific editor's technical comfort and workflow habits that don't automatically transfer to whoever replaces them. We recommend a quick recheck of the original decision whenever a client's primary content owner changes, rather than assuming the original recommendation still holds indefinitely.

At the end of this process we hand over a short, one-page summary of the recommendation and the reasoning behind it, written for a non-technical stakeholder who wasn't part of the original conversation. It's proven useful well beyond the initial decision, since it gives a client something concrete to point to during any future internal debate about whether the CMS choice was ever actually justified.

More than one client has forwarded that summary directly to a new hire or a board member asking why the company uses the platform it does, and having a clear, written answer ready has saved them from having to reconstruct the reasoning from memory months or years after the original decision was actually made, long after the original conversation and its context have faded.

A CMS decision gets treated as a purely technical choice more often than it should, when in practice it's closer to a long-term operating decision about who on the client's team can do what, independently, without needing a developer involved. Framed that way, the right answer is rarely the platform with the most features. It's the one that matches how the specific team in front of us actually works day to day.