What headless actually means
A conventional store is one system: the platform holds the products, processes the orders and renders the pages. Headless splits the last job off. The platform still holds products and takes payment; the pages are a separate application you own, asking the platform for data over an API.
“Composable” is the same idea taken further — the platform itself is broken into pieces, so search comes from one vendor, checkout from another, content from a third. Same trade-off, more of it.
What it genuinely buys you
- Speed. A purpose-built front end carries none of a theme’s accumulated JavaScript, and that gap is real rather than marginal.
- Design freedom. Nothing has to be expressed as a variation on a template somebody else designed for a different shop.
- Multi-channel. One catalogue can feed a website, an app and an in-store screen without three copies of the data drifting apart.
- Control of the buying journey. If your customers configure, quote, or buy by weight or dimension rather than by unit, you are not fighting the platform’s assumptions any more.
What it does not buy is a better shop. If the catalogue is thin, the photography is poor or the delivery promise is unclear, headless changes none of that and costs a great deal to find out.
What it costs you, beyond the invoice
| You gain | You give up |
|---|---|
| A front end nobody else has | The platform’s themes, and every app that injects into the storefront |
| Real speed | Permanent maintenance — dependencies that need updating, by somebody |
| Design freedom | The ability to change things without a developer |
| Multi-channel from one catalogue | A second system to reason about when something breaks |
| No platform ceiling | A much smaller pool of people who can pick it up after you |
Source: Cybrial’s own account, written from builds. No competitor agency has been used as a source.
The second column of row one is where these projects most often stall. A Shopify app that adds reviews, subscriptions or a currency switcher works by injecting into the storefront — and there is no storefront to inject into any more. Each of those becomes a small build of its own, and they are rarely in the original estimate.
The maintenance point is not a scare story either. A themed store keeps working while nobody touches it. A custom front end has dependencies that age, and it needs the studio that built it to still be around. That is an argument for a monthly care arrangement rather than against headless — but it belongs in the decision rather than after it.
The one test that settles it
Can you name something the front end must do that the platform’s theme system genuinely cannot?
If yes — a configurator, trade pricing rendered per customer, a buying journey that is not “product, variant, add to basket” — headless is properly on the table. If the answer is “it would be faster” or “it would look better”, it is not, and the money does more elsewhere: on photography, on the checkout, on the three pages that already get traffic.
A useful sanity check on the speed argument specifically. Most slow stores are slow because of unoptimised images, too many apps and cheap hosting — all fixable in days for a fraction of a rebuild. Going headless to fix a speed problem you have not tried to fix conventionally is buying a new car because the tyres are flat.
The version that usually wins
Not all or nothing. Render the catalogue and product pages custom — which is where the speed, the SEO and most of the design value live — and leave checkout on the platform.
You keep the platform’s payment handling, its fraud tooling and its compliance, which are the three things you least want to own. You keep the ability to walk it back. And you capture most of the benefit, because nobody ever chose one shop over another because of the checkout’s typography.
It is the answer often enough that it is worth naming before a full rebuild is scoped.
The SEO question, since it comes up
Headless is neutral for search when it is built properly and actively harmful when it is not. The failure mode is a front end that renders in the browser rather than on the server, so what arrives is an empty page and a script.
Server rendering, real URLs, canonicals, structured data and a working sitemap are all perfectly achievable — they simply have to be somebody’s job rather than the platform’s. Ask specifically how each is handled before signing anything, because “we’ll add SEO afterwards” is how headless projects lose traffic.
And whatever you do, map every existing URL to its new equivalent and redirect it. That applies to any rebuild, and it is the single most common reason one loses rankings.
