Headless commerce, or not?

Knowledge Note

Go headless when the experience you need is genuinely impossible on the platform and you have the permanent capability to own a front end — otherwise the platform is the better business decision.

One current Cralgo reading of this question — based on technical reasoning, observed situations, and open to revision as context or evidence changes.

The current reading

• Headless is an operating-model commitment disguised as an architecture choice.
• It buys experience control and composability, and costs permanent front-end ownership.
• Most performance and flexibility complaints attributed to the platform are theme, data or integration problems.
• The more useful question is not 'is headless better' but 'can we staff and standardise a front end for the next five years'.

Why the question comes up

Usually after a period of friction: the theme cannot express the design, page speed is disappointing, or a marketplace of apps has become a tangle nobody can reason about.

Headless is then presented as the escape. Sometimes it is. Often the same problems reappear with more moving parts.

What you are really deciding

A platform gives you a coherent whole: storefront, checkout, admin, upgrades and a support path. Going headless keeps the commerce engine and takes ownership of the entire customer-facing layer.

That layer then needs its own roadmap, hosting, performance budget, accessibility standard, release process and on-call. None of that is difficult in isolation. All of it is permanent.

So the honest test is a staffing and standards test, not a technology test. Organisations that pass it get genuine advantage. Organisations that do not get a slower site with a bigger surface area.

The conditions each answer suits

Situation Stay on the platform Go headless Experience needs Achievable within the theme and its extension points Genuinely impossible, and the difference is commercially material Team No permanent front-end capability Front-end capability you intend to keep for years Content and channels One storefront, one market Multiple surfaces sharing one commerce core Performance Problems trace to theme weight, media and apps Problems are structural to the rendering model Roadmap Merchandising and growth dominate Experience differentiation dominates

A partial answer exists: keep the platform and take control of specific surfaces. It is unfashionable and, in several situations Cralgo has seen, the more proportionate choice.

What to examine before deciding

Measure first. In most cases a serious audit of theme weight, third-party scripts, image handling and app overhead recovers the majority of the performance gap being used to justify the migration.

Then price the ongoing cost honestly: who owns the front end on a Sunday, who approves its standards, and what happens to it when the initial build team moves on.

• Measure

  Field data, not lab scores. Identify what actually costs you conversion.

• Attribute

  Separate platform limits from theme, app and integration decisions.

• Price the model

  Ownership, standards, on-call and roadmap for a permanent front end.

• Sequence

  If you proceed, migrate one surface first and learn from it.

If you do go headless

Treat the front end as a product with an owner, a standard and a release rhythm — the same discipline you would apply to the commerce core. Headless failures are rarely technical; they are the result of shipping an architecture into an organisation that had no structure to receive it.

Testing the decision

Run a real performance and extensibility audit and write down which limitations are platform-imposed and which are self-imposed. The list usually decides the question for you.

If the storefront is not the constraint

If merchandising, acquisition or retention are the binding constraints on revenue, the architecture question is a distraction with a large price tag.

What this reading rests on

technical reasoning, observed situations

Why it stays contextual

Technology × Organisations — the answer moves with the people and the environment, not only the technology.

What this note is not

A universal answer, a best-practice list, or evidence. It is a reusable reading that should be tested against your own situation.

What remains open

• Whether managed front-end platforms reduce the permanent ownership cost enough to change this reading.

What would change this reading

• Organisations sustaining a headless front end over years without permanent front-end capability.

Related reading at Cralgo

Architectures The D2C operating model

These informed the reading. They do not prove it.

Continue the reasoning

Why ecommerce breaks at scale Who should own your D2C technology? Do we need an order management system?

This is a current reading, not a final answer.

Back to KnowledgeExplore related Research Work with Cralgo