What Is a Headless CMS — And Does Your SA Business Actually Need One?
"Headless CMS" is one of the most misused terms in web development. Here's a plain-English breakdown of what it is, when it's worth the complexity, and when it isn't.
"Headless CMS" has become one of those terms that developers mention in proposals and clients nod along to without quite understanding. It sounds technical. It implies sophistication. It occasionally justifies a higher quote.
Here's what it actually means, when it makes sense, and when it's overkill.
The Traditional CMS Model
A traditional CMS — WordPress is the most common example — couples the content management system to the front-end presentation layer. You write content in the WordPress admin, and WordPress handles how that content is displayed on the website. The two are connected.
This works well for standard websites. The limitation is that the presentation layer is tied to the CMS. If you want to display the same content in a mobile app, a digital display, or a third-party integration, you have to duplicate it — because the content and the display are designed to work together as one unit.
What "Headless" Means
A headless CMS separates the content from the presentation. Content is stored and managed in the CMS, exposed via an API, and fetched by whatever front-end system needs it — a website, an app, a kiosk, an email template.
The "head" (the presentation layer) is removed from the CMS itself and becomes its own independent system.
Popular headless CMS platforms include Contentful, Sanity, Strapi, and Payload. Each has a different pricing and hosting model.
When a Headless CMS Is Worth It
A headless CMS makes clear sense when:
- The same content needs to appear on multiple surfaces (web, app, printed materials, digital signage)
- The development team has strong preferences about the front-end framework and doesn't want CMS constraints
- The content model is complex — many content types, nested relationships, complex media handling
- The organisation has a dedicated content team who need a professional editorial workflow
For a media company, a large e-commerce operation, or a multi-brand business, headless makes sense.
When It's Overkill
For the majority of South African service business websites, a headless CMS adds complexity without proportional benefit.
A service business website needs to display a finite set of content types: pages, services, team members, blog posts, testimonials. These don't need the editorial workflow of a news publication. They don't appear in a mobile app or a kiosk. The "content appears on one website" use case doesn't benefit from the API-first architecture.
For these businesses, the better approach is a database-driven site — content stored in Supabase or a similar PostgreSQL database, managed via a custom admin panel, served via server-side rendering. The client gets full editorial control, the developer has complete flexibility, and there's no third-party CMS dependency or monthly subscription.
The rule: if your content only needs to appear on your website, you don't need a headless CMS. If it needs to appear everywhere, you might.