A few months back, a business owner from Olching sat across the table from us, a scrap of paper in hand, and said: "I need a headless CMS." A consultant had recommended it. He ran a company with eight employees, had a five-page website, and no real idea what "headless" even meant. We talked for half an hour. In the end he got a lean, statically generated site with a simple admin backend. Faster, cheaper, less maintenance. And he was happier than he ever would have been with the headless setup.
This article explains why. No jargon, just an honest read.
What does "headless" even mean?
A normal CMS like WordPress does two jobs at once: it manages your content (text, images, prices) and it builds the finished website your visitor sees. Management and presentation live in the same system.
A headless CMS splits those two jobs apart. The CMS only handles the content and stores it in a kind of database. How that content eventually looks is decided by a separate front end. The "head" (what people see) gets detached from the "body" (where the content lives). Hence the name.
Sounds technical. It is. And that's exactly where the catch lies for most small businesses.
Why the hype exists
The idea behind it isn't stupid. Big companies often don't have one website but many places their content shows up. A website, an app, a display screen at the checkout, maybe content that appears on a partner platform too. When you change a price or a product description, you want to do it in one place and have it update everywhere at once.
For a case like that, headless genuinely makes sense. One central home for all your content, and several channels pull what they need from it. That saves double work and mistakes.
It also earns its place on very large websites with many thousands of pages, or with teams of developers who want full control over the front end. There you're talking about speed, security and flexibility at a level a standard CMS eventually can't deliver cleanly.
And why it's overkill for most small businesses
Now the honest side. A trades business in Puchheim, a tax advisor in Germering, a physiotherapist in Fuerstenfeldbruck. What do they have in common? They have exactly one channel: their website. No app. No checkout screen. No twelve partner platforms.
The core advantage of headless (one piece of content, many channels) evaporates when there's only one channel. You pay for the complexity without getting the benefit.
And that complexity is real. A headless setup needs:
- a content system running in the background (often with monthly licence fees)
- a separately built front end
- a hosting arrangement that ties the two together
- someone who actually knows what they're doing when updates or errors come up
If one of the two halves goes down, or stops fitting the other after an update, your site is dead. With a simple system, you talk to one person about one problem. With headless, often several, because the cause sits somewhere between the parts. That costs time and nerves, and the average business here in the Munich area simply doesn't have either to spare.
What we built for the Olching client instead
Back to our example. Instead of headless, he got a statically generated website. Meaning: every page is produced once as a finished HTML file and then just sits on the server. No program that has to calculate and assemble things fresh for every visitor.
The effect was clearly noticeable. The site loaded in a fraction of a second, because nothing had to work in the background. There was no database to hack and no plugin updates queuing up every few weeks. The attack surface was almost nothing.
And the content? For that we built him a small admin backend. He logs in, changes the opening hours or the text on the homepage, hits save. Done. No training needed. He told me later that his wife handles the news updates now, and she had "never done anything like that before."
Cost? A fraction of the headless offer he'd been imagining. Ongoing costs are basically just hosting. That's the part almost nobody says out loud in these consulting conversations.
So when does headless actually pay off?
So this doesn't come across as blanket rejection: there are cases where we ourselves recommend a headless, or at least a decoupled, approach. Briefly and honestly, here's when.
- You publish the same content across several real channels (website plus app plus something third).
- You run an online shop with many hundreds or thousands of products and want total freedom over the front-end design.
- You have a team in-house that looks after the tech long-term, or an agency firmly on board.
- You have a concrete plan to grow over the next year or two, so multiple channels are genuinely on the horizon. Not "maybe someday" but with an actual plan.
If several of those apply, we're happy to talk headless. If none of them do, save your money.
The honest question to ask yourself
In the end it comes down to a single question you should ask before you hand anyone a contract: How many channels am I really feeding, and who's maintaining all this in two years?
If the answer is "one channel, and I want my office admin to handle it on the side," then a lean, fast-loading site with a simple backend isn't the outdated option. It's the right one. Headless in that case isn't progress; it's a bill you pay every month for something you don't use.
Over the past few years I've seen far more businesses wanting to move back from an over-complicated setup to something simpler than the other way around. That pretty much says it all.
Technology is supposed to take work off your plate, not create new work. A buzzword in the quote doesn't make a website better. Most of the time it just makes it more expensive.
Not sure what fits your business here in the Munich area? We'll take an honest look at your situation without talking you into anything you don't need. Book a free 30-minute website check at bytebrise.com/kontakt. You'll get a clear read on whether simple or complex makes more sense for you. No sales pitch, promise.