How to choose a CMS around the way your team works

A CMS decision often begins with familiar platform names. A stronger starting point is the work your team needs to do: publish a landing page, manage translations, update a catalog or connect content with a sales process. The right platform supports those jobs without creating unnecessary operational friction. A useful evaluation includes editors as well as developers.

Map the people and content

List who creates, approves and publishes each content type. Identify what must be reusable: product attributes, author profiles, case studies or support articles. Ask an editor to complete a representative task in a prototype. A platform that looks flexible to a developer may still make a simple change difficult for the team using it daily.

Compare the complete system

WordPress, Webflow and HubSpot support different implementation approaches, but a platform name does not determine the result. Review the theme, content model, permissions, forms, search and hosting. For ecommerce, include orders, payments and inventory. Record which requirements are built in, which need an extension and which require custom development.

Decide whether headless solves a real need

Separating content management from presentation can help when structured content serves several experiences or when the frontend has unusual requirements. It introduces additional work around previews, routing and deployments. Ask who will maintain those parts. A well-designed CMS theme can be more practical when the business mainly needs an editable website.

Estimate ownership beyond launch

Include recurring fees, hosting, subscriptions, integration maintenance and editorial training. Ask how content can be exported and what happens when a vendor or developer relationship changes. Describe who owns updates and how a change reaches production. The lowest build price does not automatically create the lowest operating cost.

Build a small proof of concept

Implement one representative page and one important integration before committing to the whole site. Test mobile behavior, editor permissions, form delivery and previews of unpublished content. Document compromises and involve the client in the decision. The result should be a reasoned recommendation that fits the business rather than a preference presented as a universal answer.

A CMS trial your editor can actually run

Use the same small brief for every candidate: publish a service page with a reusable testimonial, correct a price in draft, and prepare a second language version without changing the published English page. This is an illustrative acceptance exercise, not a claim that we tested those tasks in every platform.

1. Prepare the content. Give the editor one approved service description, two testimonials with permission to publish, a deliberately long heading and one missing image. Use fictional content in the trial if permissions are unavailable.
2. Separate roles. Ask a contributor to save a draft and a publisher to review it. Verify whether the contributor can change a live page or install an extension. Write down the actual account permissions rather than assuming a role name guarantees a boundary.
3. Change one shared item. Edit the reusable testimonial and inspect both pages that reference it. Decide whether that shared behavior is appropriate; sometimes an individual page needs a deliberately independent copy.
4. Check recovery. Make an unwanted draft edit, restore the previous version where supported, and export the sample content. Confirm what the export actually contains, including image references and structured fields.

Score each requirement as demonstrated, failed or not yet verified. Keep mandatory requirements separate from preferences. An attractive editor cannot compensate for a failed mandatory publishing permission. An untested requirement remains open; it is not half a pass.

For example, imagine Candidate A demonstrates editing and export but fails the required approval boundary. Candidate B demonstrates those three requirements but needs a developer to build the reusable testimonial. A sensible next step is to price and prototype that component in B. Awarding A more points for visual polish would hide the unresolved release risk.

Record the trial date, account plan, person performing each task, observed result and any workaround. Time the task only if you actually observe it; do not turn an estimate into a measured productivity claim. This worksheet should produce a shortlist with evidence, not a universal platform winner.

For a site-builder shortlist, use the everyday editing test to check routine changes. If localization is a requirement, follow the locale publishing walkthrough before agreeing the content model. Plan the account sign-in and recovery journey separately when the project includes customer accounts.

Updated 19 October 2026: added a practical example and implementation checks. Examples are illustrative unless a specific studio measurement is identified.

Continue reading

• When does headless commerce make sense?
• A practical migration plan for CMS and ecommerce websites