Headless: the data with us, the look with you
Catalogue, prices, orders, fiscalisation and integrations stay in the system we maintain. The storefront the customer sees is built by your team and connected through an open API. The boundary is clear, so the design changes without touching the processes, and the processes improve without touching the design.
{ Why separate at all }
When the look and the processes start getting in each other's way
Headless is not a more modern version of the same thing but a different division of work. It makes sense when at least one of these four obstacles appears, not because that is how it is done now.
A ready-made theme becomes a limit
While the look resembles the competition, a theme is an advantage. The moment the brand carries the sale, every change turns into a negotiation with what the theme allows.
The channels drift apart
Site, app and in-store selling gradually acquire their own catalogues and their own prices. Data is reconciled by hand, and the differences are noticed only when a customer points them out.
A redesign means rebuilding
In single-piece solutions, changing the look also touches the selling logic, so every redesign is paid for as a new project and carries risk for the orders.
The development team waits on someone else's schedule
When a company has its own developers, they usually cannot work because of the platform's limits. An open API puts the work back in their hands.
{ What you get with the API }
Everything the admin panel does, the API does too
The system is split from the start into a part that holds the data and a part that displays it. That is why a headless setup is not a later add-on but the way the platform works anyway.
An open API for the whole catalogue and for selling
Products, categories, specifications, basket, orders, customers, reviews and vouchers are available through the API. What the admin panel can do, your system can do too, without workarounds and without reading from the database on the side.
Content and SEO data come from the same admin panel
Home page sections, banners, meta titles and descriptions are kept in the admin panel and delivered through the API. Marketing changes content on its own, even though the look of the site is yours and your team builds it.
A rendering the search engine actually sees
Pages are assembled on the server before they reach the visitor, with cached responses. That is the condition without which a headless store looks like an empty page to a search engine.
Several channels over the same data
Web store, mobile app, a separate voucher app or a display in the shop all work over the same catalogue, stock and orders. In practice we already run two separate frontends on the same foundation.
A look without the limits of a ready-made theme
The store is a project of its own, so the design does not have to fit what a theme allows. A redesign touches neither data nor orders nor integrations.
A shared foundation for every frontend
API communication, translations, cookie consent and SEO data live in shared libraries. A new channel does not start from zero.
Integrations are not rebuilt because of a new look. Fiscalisation, payments, courier services and supplier synchronisation run on the system side and are described on the page with all features and integrations.
When headless makes sense
This approach costs more and requires people to maintain the storefront. So it is only fair to say both when it pays off and when there is no reason for it.
You have your own development team
Your people hold the storefront, we hold the catalogue, orders, fiscalisation and integrations. The division of responsibility is clear, because the boundary is the API.
You sell through several channels
Site, app and in-store selling require different presentation but the same catalogue, stock and prices. Without a shared foundation each channel starts living its own life.
The look is part of what you sell
When the brand carries the sale, a ready-made theme becomes a limit. The headless approach removes that limit, at the cost of development.
You change the look more often than the processes
A redesign happens in the frontend and does not touch order processing, integrations or sales history. The switch is done without interrupting sales.
When it is not the right choice
If you have no development team, sell through one channel and your goal is to get the store running as soon as possible, the standard setup of the platform gives the same result faster and cheaper. Headless then brings only extra maintenance work, without a single advantage you would feel.
Common questions about the headless approach
What exactly does headless mean in this case?
The admin panel, catalogue, orders and integrations stay with us, while the storefront the customer sees is built by your team and connected through the API. Instead of one system doing both, you get two parts with a clear boundary.
Do we need our own developer?
For the headless approach, yes. If there is no team, we can build the storefront ourselves, but then the question is whether headless gives you anything over the standard setup of the platform.
How is search ranking handled?
Pages are assembled on the server, and meta titles, descriptions and structured data come through the API from the admin panel. Without that, a headless store loses exactly what a ready-made platform had from the start.
Can we keep our existing site?
You can, provided it can call the API. The switch is often done in phases: first catalogue and search, then basket and orders, rather than replacing everything at once.
What does it cost compared with the standard setup?
More, because the storefront is developed rather than configured. It pays off when the look and the number of channels carry the sale, and not when the goal is to get the store live as soon as possible.
Do the integrations stay the same?
They do. Fiscalisation, payments, courier services and supplier synchronisation run on the system side and are not rebuilt because of a new look.
{ How we introduce the system }
A phased switch, without interrupting sales
With a headless setup the boundary is agreed first: what stays on the system side and what your team takes over. Everything else follows the same order as the standard setup.
Analysis of the business
We go through your range, your suppliers and the way you order and deliver. The result is a list of processes that can be automated and an estimate of the time you gain by it.
Quote and plan
You receive scope, price and deadlines phase by phase. With no extra items appearing during the work.
Setup and migration
We transfer products, customers and order history from the existing system and connect suppliers, couriers, payments and fiscalisation.
Training the team
Your people are trained to work in the admin panel and receive guides they can come back to. Without training, even the best system delivers nothing.
Go-live
We carry out the switch to the new system without interrupting sales, with heightened monitoring in the first days.
Support and development
After go-live we stay available by phone and email, and we develop new features in agreement with you.