Skip to content

Blog

Features and benefits of working with a headless CMS

Michele Bianchi

How a headless CMS actually works

A headless CMS deals only with the information architecture in the back office, and serves it over APIs. You manage the site and its content without touching the frontend — the interface where people actually read it. That is the difference from a traditional CMS: content management and presentation are fully separated, which is what makes the same content usable across several digital products.

Headless CMS exist because updating content across multichannel services was painful, and multichannel stopped being unusual. Companies now expect to offer a product or a service through a website, an app and a portal at once, and a traditional CMS cannot update all three quickly. A headless CMS updates content once for every channel while leaving each frontend free to be built well, in whatever technology suits it.

Separating the creation and management of content from its presentation and consumption has several consequences:

  • Multichannel becomes normal work. With the frontend and the back office apart, the people writing content are not waiting on the people building interfaces.
  • Development gets shorter. Building against something that already exists allows real prototyping instead of a first version that has to be thrown away.
  • Secure and lean: back office and frontend are disconnected, so neither can break the other.
  • More room to design. The frontend is free to use the right technology for its context, which is usually the reason the interface is good or bad.

dotenv and Storyblok

dotenv is a Storyblok Solution Partner, listed at Community Partner level: the listing is on their site, among their partners, and opens without asking us for anything.

Knowing all that, we used a headless CMS called Storyblok for some of our clients — specifically on two projects: one portal, and one pair of websites. Our developers came out of it positive, mostly about exactly this separation between the frontend work and the back office.

Aurora, on our team, put it this way: “Being able to manage the content without worrying about the back office cut my development time significantly. Storyblok is also scalable and maintainable, which is why I could change the content completely, everywhere it appears, without going near the frontends.”

The other thing in its favour is that Storyblok is entirely cloud-based, so there is no proprietary server to configure and keep alive.

Our experience with Storyblok has been a good one — a result past what we expected, and past what the clients who trusted us with those projects expected.

A similar problem, in your company?