Headless commerce or a theme: which one fits your store

Usama · Founder

Updated 16 Oct 2026

A theme keeps editing, hosting and checkout in one place. Choose it when that place can express the shop.
Headless splits the shopper-facing site from the commerce platform. Choose it when the pages or the channels cannot live inside the theme.
Headless is not automatically faster. It is faster when someone is responsible for the front end after launch.

Choose a theme if. One team edits the shop, the page types fit the theme, and you do not want a separate site to deploy, monitor and secure.

Choose headless if. The storefront has to do something the theme system will not allow, and you have, or will hire, people who can run a front-end codebase.

Theme and headless, on the points that change the decision

Question	Theme	Headless
What drives cost	Theme and apps	Front end, the integration with the platform, and ongoing deploys
Scope	The theme path, written down before the work starts	A defined set of templates goes live on a launch date agreed in writing
Control	Inside the theme's sections	The markup, the routing and the purchase path
Speed	Depends on the theme and the apps	Depends on the front end you ship. It is not free performance
Team	Merchant editors	Editors for content, plus someone who can change the front end
Lock-in	The platform's storefront	The front end is yours. Catalogue, cart and checkout often stay on the platform

Three situations

One brand, one store, a merchant team

They publish looks and products every week and have no developer. Headless would move that weekly edit into a ticket queue. A theme, or a custom theme they can still edit, fits.

The same catalogue on a store and a live show

The show needs a page the theme cannot host: a pinned product, a cart that stays on the site, a replay that can still sell. A headless or custom front end can hold that page while the platform keeps the products and the orders.

A redesign that is really a speed project

The theme is slow because of apps and images, not because of the template language. Headless copies the same images and the same apps' data into a new stack. Fix the weight first. Move the architecture only if the theme still cannot do the job.

What headless means here

The commerce platform keeps products, prices, stock, cart and checkout. A separate front end draws the pages and talks to that platform through its APIs. Editors may still use the platform, or a content tool, for words and images. Developers own the pages.

A custom theme is not headless. It is still the platform's storefront, with your templates. It is often the middle option: more control than a bought theme, without a second system to run. The wider choice is a theme or a custom storefront.

The cost that does not appear on the first quote

Headless adds a deploy, a preview, a cache and a person who notices when the storefront and the platform disagree. If that person does not exist after launch, the store is frozen on the day we leave. We will not recommend it on that basis.

A theme's hidden cost is the opposite: apps, and the hours spent making them behave. Name that cost before calling the theme the cheap option.

What we'd build

We pick theme, custom theme or headless with the people who will run the store, and we write the choice down before the build. The service page is custom storefronts.

Custom storefronts