How to choose a CMS for your custom website

Begin with the work, not a platform shortlist

A CMS is where the website becomes part of everyday business. The most important question is therefore practical: what should your team be able to change, how often, and with whose approval? A firm publishing a quarterly insight has different needs from a hospitality group updating menus, offers and opening hours across several locations.

List your recurring publishing jobs. Include creating an article, updating a staff profile, replacing a project gallery, correcting a price, scheduling an announcement and removing an expired offer. Record who initiates each change, who checks it, how urgent it may be and whether the same information appears elsewhere. Those details reveal requirements that a generic feature comparison will miss.

Also separate content changes from design changes. Editors may need to reorder approved sections without needing control over every margin and colour. A custom-coded site can provide an excellent editing experience through a well-designed set of fields and components. The absence of an unrestricted page builder does not mean every text correction requires a developer; that depends on what the project deliberately makes editable.

Decide what your content actually is

Before choosing an editor, describe the content itself. A case study might have a title, client, sector, summary, services, narrative sections and gallery. A location might have an address, opening hours, access notes and contact details. When these concepts are explicit, they can be reused and presented consistently without asking an editor to rebuild the page each time.

Structured content is a central idea in systems such as Sanity, whose Content Lake documentation describes storing content as queryable, referenceable data. That is one implementation of the principle, not a requirement to choose that product. The useful question is whether your content needs to move between layouts, channels or languages while retaining its meaning.

There is a tradeoff. Highly structured fields create consistency but can feel restrictive when a story needs an unusual composition. An unrestricted rich text canvas allows expression but makes reuse and consistency harder. A useful middle ground is a library of approved narrative sections with purposeful fields. Prototype the most demanding real article or project, not just a short sample that conveniently fits every platform.

Compare responsibilities across the possible setups

In an integrated setup, the CMS and website presentation are closely connected. That can make preview and publishing straightforward, although the actual quality depends on the implementation. A headless setup separates the content service from the website that displays it. That can support distinct front ends and tailored interfaces, while adding integration work for preview, delivery and publishing behaviour.

A smaller site may also use content files with a controlled publishing process. That can be appropriate when changes are infrequent and a technical team remains involved. It becomes less attractive if several nontechnical editors need frequent independent updates. None of these architectures automatically produces a faster, safer or easier website.

Ask what happens when an editor presses publish. Is the change visible immediately? Does it trigger a site build? Could the build fail while the editor believes the update is live? What happens if the content service is temporarily unavailable? For example, a prebuilt site may continue serving its last successful version, while fresh updates wait. The decision should include that operational behaviour in plain language, with responsibility assigned for failures and recovery.

Test the editorial experience with a real task

Request a working prototype and let the intended editor use it. Give them an existing article, a new image and a correction to make. Observe where they hesitate. Can they understand the fields, preview a narrow screen, share a draft, schedule it if needed and confirm that the public page changed? A polished vendor demonstration is less informative than this ordinary sequence.

Test roles using separate accounts. The WordPress roles documentation, for example, distinguishes contributors who cannot publish from authors who can publish their own posts and editors with broader content responsibilities. Other systems express permissions differently. Verify the exact actions your configured roles allow, including deletion, media access and changes to shared content.

Recovery belongs in the demonstration too. WordPress documents comparing and restoring revisions; any shortlisted implementation should make its own recovery behaviour clear. Deliberately introduce a harmless mistake in the prototype and restore the previous content. Find out what is versioned, how long history is kept and whether images or linked records recover with the text. An undo button is valuable only when its scope matches the mistake.

Price the operating model and the exit

The subscription is only one part of the cost. Include implementation, editor training, hosting, monitoring, support, upgrades, integration maintenance and the time spent publishing. Check the current plan terms for users, environments, content volume, API use and any approval features you need. Avoid basing a long-term choice on a promotional price or a feature that requires a different tier.

Discuss ownership and portability before signing. Who owns the service account? Who can export the content and original media? Does an export preserve references, categories and other relationships, or only the visible text? Ask the team to demonstrate a small export and explain how another developer would interpret it. Every system has some switching cost; clarity makes it manageable.

Also establish who responds when an integration changes or publishing stops working. A managed content service may maintain its platform, while the agency still maintains the custom website and connection to it. A self-hosted system may give more operational control while requiring a different maintenance commitment. Document those boundaries so a problem does not bounce between suppliers while the marketing team waits.

Give each candidate the same publishing exercise

Prepare one small packet of real content and use it in every demonstration. Include a project with an unusually long name, several images, a related service and a draft correction. Ask the person who will maintain the website to perform the exercise, while the supplier explains only when needed.

1. Create the draft and identify which fields are required.
2. Preview the result at mobile and desktop sizes.
3. Replace an image without changing the layout accidentally.
4. Correct a relationship or reusable piece of content.
5. Publish, then demonstrate how to recover the previous version.

Record where the editor hesitates, where the interface prevents a mistake and where help is required. A feature may technically exist yet remain impractical for the person doing the work. Ask which parts depend on the chosen plan or custom development, and have those dependencies included in the quote.

Carry the results into your ownership-cost comparison. A familiar demo is useful evidence, but it does not replace the maintenance and access plan for the chosen system.

Use a weighted decision, with a few hard requirements

Create a scorecard around the jobs you listed at the beginning. Give greater weight to the work your team performs frequently and the failures that would be most disruptive. A sophisticated localization feature should not outweigh a confusing daily editing process if you publish in one language. Conversely, a familiar editor is insufficient if it cannot support a required approval workflow.

• Publishing: Can the team complete routine tasks without workarounds?
• Structure: Can the content be reused without duplicating facts?
• Control: Are permissions, preview and recovery appropriate?
• Operations: Are costs, support and publishing failures understood?
• Portability: Can the business retrieve its content and assets?

Mark any true nonnegotiable as pass or fail before adding weighted scores. Then write a brief explanation of the chosen option and its accepted tradeoffs. Include the prototype tasks and handover requirements in the project scope. That record gives the business a useful basis for judging the finished CMS: whether its people can publish accurate, well-presented content with confidence.