Blend has a new CMS partner! Check out all the details on our newest supported platform.

Lessons Learned from Building an Optimizely SaaS Site

I’ve been building websites in content management systems for almost 20 years now. And the majority of those sites have been built in what we might call a traditional, coupled CMS, where a single application is responsible for both the management and rendering of content. But like so many, I’ve been diving to headless, specifically building a new site in Optimizely’s Software-as-a-Service (SaaS) headless offering.

Authored by

Categorized

  • Development
  • Strategy
  • Optimizely

For reference, a headless CMS is one in which the CMS manages content, and any number of rendering applications deliver that content in whatever format is needed, wherever it is needed. These applications may be websites, mobile apps, VR experiences, or whatever other content delivery mechanisms one could imagine. The headless CMS only cares about the content, and the delivery apps only care about delivery. A traditional CMS does both.

As I wrap up my first major project in Optimizely SaaS, I’ve picked up a few things I’d suggest one considers when making a similar shift.

First, it’s a mind shift. You’re trading some flexibility for agility.

  • In a traditional CMS, with enough time and duct tape, you can modify and extend the editorial interface extensively (arguably too extensively in many cases). In SaaS, you work within the limits of the editorial interface.
  • In the traditional CMS, the rendering system is generally fixed and you work within the limits of the CMS rendering engine. In headless, you’re building the rendering engine. It can do and be anything you need it to.
  • In a traditional Optimizely CMS site in particular, deploying updates and fixes through the full environment pipeline can take significant time, but in SaaS, I can often have a fix out to the front end in a matter of minutes.
  • In a traditional CMS, I can decide when to apply and deploy upgrades. In SaaS, I don’t even think about upgrades because that just happens magically.

Second, intentionality and planning are much more important. While intentional and planning well are key aspects of any successful project, traditional CMS developers have often been able to get away with “short-cuts.” For example, I’ve seen many projects that have no limits on what types of blocks of content can be placed in different parts of a page (or even nested in other blocks of content). With headless, because you as the developer are writing the queries and rendering engine, you need to anticipate precisely what kind of content you are querying and rendering. This will be much easier if you’ve planned accordingly.

There are things I love about the new headless system: deployments take no time, and SvelteKit is a breath of fresh air. And there are things I dearly miss from the traditional CMS, such as deep customization of the rich text editor and event hooks hosted within the CMS. Ultimately, the choice between traditional CMS and headless often boils down to priorities. For more control and less flexibility, a traditional CMS might be a better choice. For agility and flexibility in rendering, headless might be a better fit. Generally both can do just about whatever you need them to do, but one may be better suited than the other.