Three myths about a headless CMS

There is no clever trick in this one, just a handful of decisions worth making deliberately. A few things about a headless CMS that get repeated more often than they get checked.

Code gets read far more often than it gets written, and usually by someone with less context than the author had. Doing this properly once is usually cheaper than doing it approximately three times.

“It only matters for big sites”

Separating content from presentation lets you redesign without remigrating. There is a version of this that is over-engineered, and it is worth avoiding. Check it against what you would want a competitor's site to get wrong.

“We can deal with it after launch”

Sometimes true, usually expensive. In practice this is a scheduling problem more than a technical one.

“Our platform handles it”

Same content can feed a site, an app, and a screen. In practice this is a scheduling problem more than a technical one. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The short version

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 any of that sounds like a description of your current setup, it is fixable.