Headless CMS vs classic PHP: do we really need to overcomplicate to exist?

The new technical reflex
Today, it is hard to launch a web project without hearing about “headless CMS”. The term is everywhere—in meetings, in recommendations, in invitations to tender. It reassures people; it gives an impression of modernity, almost as if it has become a must-have. By comparison, saying you are building a “classic” PHP site almost feels like you are doing something outdated. But behind this opposition, a simple question deserves to be asked: are we really choosing a solution because it fits the need… or simply because it is trendy?

Two ways of doing things (without the fluff)
A classic site is the easiest model to understand. You write your content in a tool, and it is displayed directly on your site. Everything is connected, everything works together, straightforwardly. Headless works differently. Your content is stored in one place, and your site fetches it to display it. There is an extra step in between. It is invisible to the user, but it completely changes the way the site is built. It is not necessarily better. It is simply another way of doing things—a bit more technical, a bit less direct.

An appealing promise… but it comes at a cost
The reason headless is so appealing is that it offers more freedom. It allows you to create more advanced experiences, use modern technologies, and reuse the same content in multiple places, for example on a website and in an app. On paper, everything looks more flexible, more scalable, more ambitious. In reality, it also requires more work. Projects become more technical, teams need to be better organised, and every single change can require more intervention. What you gain in freedom, you pay for in complexity.

The risk of overcomplicating for nothing
This is where many projects go wrong. An advanced solution is chosen when the need is actually simple: a showcase website, a few pages, content to be updated every now and then. Nothing that justifies a complicated architecture. And yet, a rather heavy machine is set up to handle it. The site works, of course. But it becomes harder to maintain, to develop, and sometimes even to understand. It is a bit like using a tool that is too powerful for a basic need. You end up losing time exactly where you wanted to save it.

The temptation of “we’ll see about that later”
We often hear that we need to think about the future, to anticipate, to build something scalable. The intention is good, but it is often vague. To evolve, yes. But towards what exactly? If this future is not clearly defined, we run the risk of overcomplicating the present for something that might never happen. We build a solution for a hypothetical problem, instead of simply meeting a real need.

So, when should you use what?
In practice, it all depends on the project. A classic site remains perfectly suited as long as the need is simple and clear: presenting a business, publishing content, being visible online. In these cases, the main goal is to move fast, stay efficient, and keep the tool easy to use. Headless becomes interesting when the project changes scale. For instance, when content needs to be used across multiple platforms, when the user experience becomes more advanced, or when the site is part of a larger ecosystem. There, the complexity makes sense, because it meets a real need.

A matter of common sense
At its heart, the decision is quite simple. You just have to ask yourself where the complexity is coming from. If it comes from the project itself, its use cases, or its ambitions, then a more advanced solution may be relevant. But if it comes solely from the technical choice, then there is a good chance it is not the right option.

In short
Headless CMS is not a revolution. Classic PHP is not outdated. They are simply two ways of building a website. The real challenge is not to use the most modern solution, but the one that fits the project. Because in the end, a good site is not one that impresses technically, but one that works, simply and efficiently.