How to choose a CMS for a consumer brand website

Most CMS conversations start in the wrong place. Teams compare pricing pages, sit through demos, and make a decision based on what they already know. It's understandable. It's also the wrong order of operations.

A CMS is not a technology decision. It is an editorial decision with technology consequences. The question is not which system has the most features, but which system fits how your brand creates, manages, and publishes content, today and three years from now.

At Livewall, we build digital products for consumer brands in retail, FMCG, and entertainment. Choosing and integrating CMS solutions is a core part of our web application development work. Here is what we keep seeing go wrong, and how to approach it better.

Start with the editor, not the developer

The people who suffer most from a poor CMS choice are rarely the people making the decision. Developers can usually work around limitations. Editors cannot.

Ask your marketing team: what does a typical working week look like? How many pages get updated? Who does it? Do they need a developer for every change?

If your team updates content daily across multiple channels, you need a headless CMS with a strong editor interface. Storyblok, Contentful, and Sanity are all solid options. If you have a relatively static marketing site with occasional updates, something simpler will do.

The classic mistake: choosing a headless CMS for a team that has never worked with structured content before. The technology is right, but the editors are frustrated. Six months in, nothing gets updated.

Editor experience is not a soft requirement. It is the primary filter.

Content ownership: what do you actually own?

This is the conversation nobody wants to have until it is too late. Some CMS platforms store your content in a proprietary format. Migrating away becomes expensive and time-consuming.

Questions to ask before you commit:

• Can I export my content in an open format?
• What happens if the vendor raises prices, gets acquired, or shuts down?
• Who has access to my data, and where is it stored?

We strongly favour API-first and headless architectures for exactly this reason. Your content lives in a neutral system. Your frontend can be replaced without losing everything you have built.

For Eindhoven Airport, we built a modular website where the editorial team manages pages entirely on their own. The CMS choice was part of a broader digital strategy built around editorial independence and long-term ownership.

Integrations: the real technical test

A CMS never operates in isolation. It needs to connect with your e-commerce platform, CRM, loyalty system, analytics tools, and campaign stack.

For consumer brands, we see the same integration requirements come up repeatedly:

• Product data pulled from a PIM or e-commerce backend
• Campaign pages connected to a loyalty platform
• Personalised content driven by customer data
• A/B testing and experimentation tooling

A good CMS has a mature API and an active connector ecosystem. But the question is not just whether the integration is possible, it is who maintains it. Every integration is a dependency. More dependencies mean more maintenance.

We regularly build web applications where the CMS is one component in a larger architecture. The CMS decision affects everything downstream: deployment, performance, content workflow, and the ability to scale into new markets.

Headless vs. traditional: an honest assessment

Headless CMS is not always the better choice. It is more complex and demands more from your technical team. If your brand runs a single website with a stable structure, a traditional CMS like WordPress or Craft CMS is perfectly fine. You should not pay for flexibility you do not need.

Headless makes sense when:

• You publish the same content across multiple channels (web, app, kiosk, partner platforms)
• Performance and Core Web Vitals are business-critical
• You want to use a modern frontend framework
• You expect significant growth in content volume or new markets

In our digital product work, we default to headless architecture because the brands we work with almost always have multiple touchpoints. But we are honest when a simpler solution is the better fit.

The question we always ask: which CMS choice will you still be happy with in three years?

What we look for at Livewall

We work with several CMS platforms depending on the project. No single system is the universal right answer. But we always apply the same criteria:

Editor experience first. If your team does not enjoy working in the system, content becomes a bottleneck.

Open standards. Choose a system that stores content in a portable format. Vendor lock-in is a business risk, not just a technical one.

Integration maturity. How many connectors already exist? How complete is the API documentation? What does the developer community look like?

Performance by design. A headless CMS paired with a static frontend delivers stronger Core Web Vitals by default than a traditional monolithic setup.

Scalability. Do not design for today. Design for what you will need in two years: new markets, additional channels, higher content volume.

As a web development agency, we think deliberately about the long-term consequences of every CMS decision. Not just for the build, but for the daily editorial reality your team lives with afterward.