Answers

Headless commerce, and whether you actually need it

Headless commerce means running your store as two separate systems that talk over an API: a commerce engine that owns the catalog, cart, checkout, and orders, and a frontend you build and control on your own. For most stores the honest answer is that you do not need it, and the ones that genuinely benefit share a specific constraint that a standard theme cannot bend around.

The word comes from the architecture. The storefront people see is the head. A normal platform ships the head and the engine welded together, so your theme and your cart are one product. Headless cuts the head off and lets you attach your own, which buys you total control over the frontend and hands you the bill for building and maintaining it.

What headless actually changes

In a conventional build, your platform renders the pages, runs the cart, and serves the theme from one codebase. A customer request hits the platform and the platform returns a finished page. You customize within the limits of the theme system, and apps plug into hooks the platform exposes.

In a headless build, the platform becomes a data source. Your frontend, built in a framework of your choosing, calls the commerce API for products, prices, and inventory, renders the pages itself, and sends cart actions back over that API. The two halves deploy on their own schedules. Nothing about the way a product looks is dictated by a theme anymore, because there is no theme.

When headless earns its complexity

Headless is a tradeoff, not an upgrade. It is worth the extra moving parts when one of these is true for you:

• You need a frontend the theme system genuinely cannot produce: a bespoke configurator, a content-led experience that is half magazine and half shop, or an interaction model the platform fights you on.
• You are serving one catalog to several faces at once, such as a website, a native app, and an in-store kiosk, and you do not want to rebuild the commerce logic three times.
• Your content lives in a separate system you have already committed to, and you want editorial pages and product pages to share one tightly integrated frontend.
• You have the engineering capacity, in-house or retained, to own a frontend codebase and its deploys for the life of the store, not just at launch.

When it is the wrong call

Most stores land here, and there is no shame in it. A well-built theme on a hosted platform is simpler, cheaper to keep alive, and faster to change. Headless is probably the wrong call when:

• Your catalog and checkout are conventional and you mainly want the store to look sharp and load fast, both of which a good theme delivers without decoupling anything.
• You rely on the platform's app ecosystem, because many apps assume the standard storefront and quietly stop working, or stop injecting their interface, once the head is gone.
• You value the native theme editor, instant previews, and the ability for a non-developer to change a page, all of which you give up when the frontend becomes custom code.
• You do not have anyone to maintain a second codebase, and the store would stall the first time the frontend broke and no theme was there to fall back on.

The costs a theme hides from you

A standard theme quietly gives you a large amount of work for free, and headless hands that work back. You rebuild the cart interface, the account pages, the search, the collection filtering, and the many small states a mature theme already handles. The checkout is the sharpest edge: on several major platforms the checkout still runs on the platform's own hosted pages for security and compliance reasons, so a store described as fully headless usually still bolts onto a checkout it does not fully control.

None of that is a reason to avoid headless. It is the reason to be honest about what you are signing up for. You are trading convenience for control, and you only come out ahead when you actually use the control.

How we decide for a store we build

We treat headless as a decision with a burden of proof, not a default. If the frontend you need can be built well inside a theme, we build it inside the theme, because fewer moving parts is a feature. We go headless when the constraint is real: a frontend the platform cannot express, several channels sharing one catalog, or a content and commerce hybrid that has to feel like one site. Because we do this work only on sites we build, the architecture is chosen once, at the start, rather than bolted on later. For how we scope a store and what the build includes, start with the overview at /services/web-design/, and if you are weighing a platform theme against a full custom build, the question at /answers/ecommerce/shopify-or-custom/ is the better next read.