A short guide to a headless CMS

It is rarely the thing that gets a project approved, and often the thing that decides how it goes. Everything we would tell a client about a headless CMS in the time it takes to drink a coffee.

The question is rarely whether something can be built, but what it costs to keep running afterwards. If it only works because one person remembers to do something, it does not work yet.

The reason this keeps coming up

Separating content from presentation lets you redesign without remigrating. Where this goes wrong is almost never a lack of knowledge. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

The practical version

Editors get a proper interface instead of raw markup. Where this goes wrong is almost never a lack of knowledge. It is the sort of thing that looks like polish right up until it costs you an enquiry.

Warning signs

Same content can feed a site, an app, and a screen. That sounds obvious written down. It is still the thing most often skipped. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

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
• Separating content from presentation lets you redesign without remigrating — 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.