A headless CMS: what to get right first

There is no clever trick in this one, just a handful of decisions worth making deliberately. If you only fix one thing about a headless CMS this quarter, make it the first item below.

Most development decisions are really maintenance decisions wearing a different hat. Check it against what you would want a competitor's site to get wrong.

Start here

Separating content from presentation lets you redesign without remigrating. It is worth being explicit about, because assumptions differ quietly. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Then this

Editors get a proper interface instead of raw markup. This is the sort of thing that compounds, quietly, in both directions. The teams that stay on top of it are the ones who put it on a calendar rather than a wish list.

Eventually

Same content can feed a site, an app, and a screen. None of that requires a large budget, only a decision and someone to own it. Most teams find the first pass takes an afternoon and the maintenance takes minutes a month.

How to tell if yours is fine

The question is rarely whether something can be built, but what it costs to keep running afterwards. 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

The point is not perfection, it is knowing which of these you have consciously chosen to skip.