The Headless CMS for Websites

One of the main drawbacks to Headless CMS is that most solutions are “blank boxes”. Hence, content modellers and developers have to set everything up from scratch, including things every website needs like SEO, URL management and hundreds of other “little jobs” that come as a default with all-in-one solutions. As this blog explores, it doesn’t have to be this way. Contento was built in part to solve this very annoying problem. 

Why reinvent the wheel every time?

In recent years, the Headless CMS category has exploded. Lots of VC cash swirling around, hundreds of new entrants, and eye-watering growth rates for Headless CMS incumbents. 

In part, the drivers of growth have been the hype - a shiny new thing to try out, but also due to increased dissatisfaction with legacy solutions from traditional monolithic providers like WordPress. There is a growing sense that it is no longer fit for purpose, especially for commercial websites that are looking to scale.

The Headless CMS category also offers several distinct advantages, ones that sit well with a certain cohort of users - primarily scaling businesses. For these, beautiful bespoke design, speed and improved security are key criteria. An out-of-the-box template from WordPress (on an inherently insecure platform) won’t suffice for this category of user.

While Headless delivers unrivalled advantages in terms of enhanced security, unmatched performance (page load times) and it’s scalability (especially for omnichannel) there is one significant issue that is not widely discussed - the blank box problem.

So what is this problem and why is it such an issue?

Because a Headless CMS is ‘head agnostic’ most do not make assumptions about the end use of the data residing in the back-end repository. While this lends itself well to omnichannel delivery (where data is pulled to various front ends) the glaring oversight is that in the majority of cases, the data is being used to power a website. 

By ignoring this basic fact it means that in most solutions the feature set is not aligned on this use case - despite it being the dominant one. As a result, the conditions are such that there is a lot of heavy lifting needed for each website build. In most cases a senior developer is needed, such is the complexity (and volume) of ‘jobs to be done’ which serves to push the overall cost of development up. Cost that gets pushed to the end client. 

It is one thing for a client to pay for beautiful bespoke design, but quite another to be paying to have someone constantly reinvent the wheel, and needing to spend an inordinate amount of time on front-end development. 

To complicate matters further, many headless builds are on the back of website migrations, which means there is a cost to the migration to also factor in, but also an expectation that the new website will function like the old. Most marketing teams will “want a setup” just like their old WordPress one, which was undoubtedly fueled by tens of Plugins designed to extend core functionality. 

The net effect is the delivery costs spiral, timelines extend and client dissatisfaction ratchets up.

Is it any wonder that there is increasing push-back against Headless deployments?

However, it doesn’t have to be this way.

How Simple Assumptions Can Transform Headless?

Instead, consider an assumed position from the perspective of a Headless CMS vendor. 

What if we assumed the primary use case was in fact a bespoke website? 

With this simple assumption, everything is transformed. Why?

Well, you can operate a ‘jobs to be done’ philosophy when it comes to building out the feature set, obsessing on how your CMS is actually used, and seeking to make every step more efficient. 

And this is what we’ve done with Contento (a headless CMS 100% focused on websites).

What are the tasks a developer needs to do to get a site live?

Why reinvent the wheel every time?

Starting here is a very different place to an open box or blank box starting point.

As a result, we’ve been able to bake in features that are table stakes for a website build, be that a dedicated SEO module or a content workflow feature, features you’d never include in a Headless trying to be “all things to everyone”. 

A nuance to our position is we’ve also tried to make Headless more accessible to junior developers so they can grow in confidence, something that is not the case with most of the leading Headless CMS vendors on the market. 

An additional consequence of an assumed use is feature deployment is a lot more considered. Whereas with the blank box approach common with most Headless CMS vendors, feature bloat is becoming more common, and usability has started to suffer. 

Most of these solutions are also very developer-centric, whereas, at Contento, we’ve paid particular attention to the needs of both the content and marketing functions so that they don’t get overwhelmed when managing and maintaining a website.

The Headless CMS for Websites seems like such an odd title. 

Whatever does that even mean?

Surely CMS are built for websites. 

While that was undoubtedly the case with legacy monolithic CMS like WordPress, this simple assumption is not correct when it comes to most Headless CMS solutions. 

After all a crucial distinction is that they are usually ‘head agnostic’ - and thus not concerned with the front end. 

That is someone else's problem. 

The net effect is that most Headless CMS builds suffer as a result. 

Senior developers are needed, reusability is low, and time taken on repetitive tasks is often significant. All of which leads to an inflated final bill, that leads to dissatisfaction all round. 

Recognising this issue was common, we felt there were significant advantages for web development agencies (and ultimately clients) if we built features that sought to address these very issues.

These include:

• Starter Kits (sets up the site structure for you including Next.js code templates, content types, assets and example content.)

• Content Workflow (content ops for you and your team - again a feature you won’t find in most Headless CMS)

• SEO Module (flexible and customisable SEO field mapping and Google preview)

• Content Library (pre-built content types to speed up the development process.)

• Image Optimization (optimize images on the fly via a simple URL syntax and have them delivered at speed from our global CDN)

• Visual Preview (preview content from the Contento editor)

In isolation these features may not seem like a big deal, however, collectively, when married to lots of other design elements there are two significant outcomes.

1- Time to build declines significantly

2- More junior developers can build in confidence

And marrying these shave time and cost off Headless CMS builds leading to an increase in client satisfaction.

In summary, by taking an assumed position as to the primary use case, we have been able to shape the feature set to align with this. The net result is a CMS that saves developers a lot of time without compromising on quality.