When a headless CMS is worth the effort

Teams tend to reach for this after something has already gone wrong. A headless CMS is not free, and pretending otherwise leads to bad decisions.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Budget a little time for it every quarter and it never becomes a project of its own.

When it is worth it

Separating content from presentation lets you redesign without remigrating. Small and consistent beats large and occasional here. It is the sort of thing that looks like polish right up until it costs you an enquiry.

When it is not

If nothing downstream depends on it and nobody is complaining, it can wait. There is a version of this that is over-engineered, and it is worth avoiding.

How to decide

Same content can feed a site, an app, and a screen. That sounds obvious written down. It is still the thing most often skipped. It is the sort of thing that looks like polish right up until it costs you an enquiry.

In practice

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about a headless CMS before you move on:

• Someone can say what the current setup is without going to look
• Editors get a proper interface instead of raw markup — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you are not sure where your systems currently stand on this, it takes us about an hour to find out.