- I think headless is good - for those who need it
As the technology company Dekode is then we get many requests about which type of strategy is right to choose for a given client . Several of those who contact us have often been in dialogue with several companies. They have also received different recommendations on which direction they should take when it comes to technology. One of the terms that comes up most often in our dialogues is Headless. But what does it really mean to have a headless website?

What is headless?
Directly translated, headless is headless. This means that the website's visual interface and administration interface are two different systems. In other words, they are disconnected and developed as two separate systems. The interaction between the two takes place using interfaces that facilitate computer to computer communication. Or an API as it is called. The systems are often run on different servers as well. In the past, web publishing systems have been responsible for both content management and content presentation. It is precisely this separation between administration and presentation in different systems that is Headless.
So why is there so much talk about Headless anyway? And who is it that should have a headless website?
The first question I think we should ask ourselves is: What is the website going to do for my organization?
The need the website will solve is a crucial factor. Will the website solve a communication need? Trigger sales in the form of services? Drive direct sales or solve complex user needs? In many organizations, there may be several of these.
We can make this a little more concrete with an example that is relevant to many of ours clients . We in Dekode have many clients within the social benefit segment. Organizations that have both a great need for communication and that the website can facilitate the sale of products and fundraising. Relatively large tasks for one website to solve with many different systems in the background, each with its own special field. A bundle of systems that will solve communication, sales and customer management. Is headless the way to go for one like this client ?
Microservice architecture
If we were to solve this specific example with headless, we could develop this case with a microservice architecture. Another term that many people are familiar with. Instead of creating a large system, the system is divided into many small parts that are sewn together for the users. In an ideal world, the user does not notice that they are navigating between these. Each individual part of the website has completely dedicated tasks. One part of the website solves communication, another part solves online shopping. The third part handles fundraising and the fourth takes care of customer data such as personal information and order history.
Furthermore, it's up to the visual team to stitch this together. But with that, we might need a fifth system that allows editors to combine all these data sources so that it looks good to the user. For the user to experience all these parts as one ecosystem, it also makes sense to have a design system that embraces all the above parts of the user journey.
By doing this properly, you can get a well-functioning system that has fewer tasks and dedicated people who maintain the different parts. The web team implements the sub-components and makes them talk to each other.
- I think many people ask for headless without knowing what it means, and are influenced by the fact that the term has become so popular
In principle, headless is a scalable method for creating web solutions. However, there is a chance that you are now thinking about your own organization and assessing whether you have the necessary resources to carry out such a project. And, not least, whether the people who will be working with the web solution have the necessary knowledge needed to maintain such a system. Is it financially viable to have so many dedicated roles?
Personally, I've worked with headless for a number of years in an organization where headless was absolutely the right way to go. I worked in an organization where the product was a streaming music service. The systems to run such an organization are not exactly something you can buy from just any vendor. We implemented microservice architecture and all data was exchanged via APIs. We had dedicated teams for each system and dedicated design departments for both the website and the apps we sold.

As I think you understand, I believe that headless is very good - for those who need it. I think there are many people who ask for headless without knowing what it means and are influenced by the fact that the term has become so popular. I don't mean this because Dekode primarily works with WordPress. There are very good opportunities to do headless with WordPress. I myself have chosen headless WordPress for sub-components in the above company. I believe that decisions are driven by what is popular and not necessarily what is best for the organization or the customer.
If we flip the example above with a charitable organization and implement this with WordPress, we can solve the presentation layer for communication, the online store and fundraising in one system. All of these can be managed in the same interface. All systems used by the organization will be updated when customers take actions on the website. Editors can work with content and combine all the parts they need without switching systems. They use visual content blocks that are in line with their own design system in an interface that is visually similar to what customers will be faced with. "When we see that it makes sense to create something headless, we do it as an integrated part of the web solution, but make sure that the publishing and maintenance of the website is easy to understand and visually appealing.
WordPress or headless WordPress?
Our approach is to take a pragmatic approach to the customer's needs that solves the organization's needs in a way that is sustainable for the customer. WordPress is an open source system. However, that doesn't mean WordPress can't be adapted to the customer's needs so that it becomes the customer's tool. And yes, we also use third parties to streamline data exchange between different systems. But then we always have a common source that sends the data - namely WordPress.
At Dekode , we work hard to create good editing tools. We want the editorial experience to give the best possible impression of the finished pages during the editing process. We do this by creating libraries of content blocks or modules. To facilitate this, we code the blocks in the administration interface with React. By using headless, all these blocks must also be developed for the front-end framework in the framework used. When developing something headless, you also have to take into account that all other aspects of building a website must be developed from scratch, including menu structures, URL structures and everything related to search engine optimization. You also need to develop all the tools that will be used for commercial purposes, such as tracking and integration with analysis tools.
A pragmatic approach
Dekode can deliver both regular WordPress and headless WordPress, or headless anything for that matter - but we have good arguments when we choose it. Instead of pushing headless on one client who don't need it.
You should be pragmatic about the technology you choose so that you don't let the technology control how the organization should work. Done correctly, there is a lot of technology that can help organizations achieve their goals. By being aware of where to start from scratch and which areas should be facilitated so that editors can do their job independently of a development team - then I believe that you have started at the right end.
Mollie
We are in dialogue with several of ours clients who have wanted headless went through the same rationale as described above. By going in-depth into the needs of the customers, there are few cases where we have found that it is necessary or a good use of resources to develop a headless platform. One of the last cases where we landed on this particular choice was for Mollie. Mollie is a Dutch payment provider.

Their services do that clients on a website with just the click of a button access to a large number of payment solutions.
Mollie's organization requires a combination of several types of solutions - both headless and non-headless - but for their global website they chose to use WordPress in the usual way.
In particular, this choice was based on two key factors: the editors at Mollie need a tool that is adapted to their needs and they are dependent on a tool that is widely known by content creators. And they wanted a platform where they could iterate faster without having to maintain multiple codebases to achieve the design-driven interface they want their customers to encounter.
Today, Mollie is well equipped to scale to new markets beyond the 7 they are present in. Their goal is to make online payment solutions easier. We at Dekode are proud to be able to help companies like them achieve their goals.
And not least to create a good solution that suited their needs - headless or not headless.