Content Management Systems

Who touches a page before it goes live?

More people than the org chart suggests. A writer drafts. An editor reads it and sends it back. Someone finds an image and someone else checks the licence on it. A manager approves it because a policy says they have to. A campaign has a date on it that was agreed somewhere else, so the page cannot go live early and cannot go live late. None of that is unusual. It is what publishing looks like in any organisation with more than one person in it.

The tool has to hold that sequence. Most hold part of it, and the part they miss gets paid for daily: a spreadsheet tracking what is approved, a chat thread standing in for a review step, a field labelled Subtitle carrying something that is not a subtitle because there was nowhere else to put it. Each workaround is small on its own. Together they are why nobody can say with confidence what is approved, what is scheduled and what is live.

How unusual is your publishing?

The question is not which product is best. It is how much of the way you publish is ordinary. Content in a shape most organisations share is content the shelf already models, and paying to rebuild that is paying twice. Off-the-shelf means one installed product doing the editing, the storage and the published site together.

Where the front end is the ambition and the content behind it is recognisable, that bundle comes apart. Headless keeps a hosted editor and a content API on one side, and lets the site itself be built however you like on the other. Where the publishing process is the unusual part (many hands, many stages, formats moving on a fixed date), the editing experience is the thing that needs designing. Custom means bespoke content models and editorial tooling built on a headless or low-code foundation, with engineering reserved for what has no shelf equivalent.

Off-the-shelf, headless or custom is a build decision, and rarely the first one. Settle how you publish before you settle what you publish with. When it is time to settle it, we are not tied to a platform and pick the one the job asks for. Many of our projects run on Framer or Webflow. Flat files in Git suit documentation and simple static sites. Sanity suits work where the data model is doing the heavy lifting, and Payload where the system has to live inside a TypeScript application.

There is a newer job on that list too. MCP, the Model Context Protocol, is the interface an AI agent uses to reach a system through its API, so a CMS that speaks it can let your own agents read your content, keep it current and draft into it. Directus and Cosmic JS both do. We built The London Practice on Webflow, and what makes it fit is not the platform but what sits on top of it: interconnected collections and conditional rendering, shaped around the way somebody chooses a practitioner.

When is a custom CMS worth it?

When the way you publish is part of how you compete. An editorial operation of any scale is a machine with many hands: writers drafting, editors approving, designers fitting images and layouts, campaigns landing on dates that do not move. Off-the-shelf tools model a generic version of that machine, and the difference between generic and yours is paid daily in workarounds: content squeezed into fields meant for something else, approval chains run over email because the tool has no place for them, and formats the template never imagined managed by hand.

A custom CMS earns its cost by deleting those workarounds at the source: content modelled as your formats actually are, roles and approvals matching your real chain of command, and the repetitive work (resizing, scheduling, cross-linking) done by the system rather than the staff. Editorial hours come back, and the mistakes that came from working around the tool stop happening. If that description sounds like your operation, the shelf is costing you more than the build would.