Shopify Plus or headless commerce: choosing for your catalog and your team

Headless commerce arrives in most companies as an aesthetic preference that gets rationalised afterwards. Somebody wants a front end that feels bespoke, a supplier is keen, and a performance argument gets assembled to support a decision already made.

Sometimes it is right. It is right less often than it is chosen, and the reason has almost nothing to do with technology.

What headless actually changes

The word suggests removing the platform. It does not. Shopify’s Storefront API lets you build your own storefront against Shopify’s commerce data, using Shopify’s own Hydrogen framework or any other. Everything else stays where it was.

This matters commercially. If the reason you are considering headless is a checkout requirement, headless will not deliver it, and you can probably get what you want on a theme.

The costs that are published, and the one that is not

Shopify Plus starts at $2,300 a month on a three-year term, or $2,500 on a one-year term, and those are the same whether your storefront is a theme or an application. Shopify describes them as starting prices with a variable platform fee available for more complex structures. Using a payment processor other than Shopify Payments adds 0.20% per transaction paid to Shopify. Nine expansion stores are included, and further ones are $300 a month each.

On hosting, Hydrogen storefronts deploy to Oxygen, Shopify’s own hosting, which is included on paid plans. So the honest statement is that headless does not necessarily add a hosting bill, and anyone telling you it always does is describing a different architecture.

The cost that is not published, anywhere, credibly, is the build. Ranges circulate widely and they are agency marketing, not survey data. We are not going to repeat them. What we will say is that the build is the smaller number, and the one that gets underestimated sits below.

The real cost is a standing team

A themed store can be run by people who are not engineers. A merchandiser changes a banner, reorders a collection, edits a landing page and publishes, using the theme editor, on a Tuesday afternoon.

A headless storefront is an application. Content changes that were self-service become a ticket, a branch, a review and a deployment. That is not a criticism of headless, it is what an application is. But it moves work from a marketing team to an engineering team, permanently.

This is the same dynamic as any custom build. Roughly 60% to 80% of a system’s lifetime cost lands after launch, and a headless storefront converts a rented, maintained front end into one you own and maintain.

What you give up, specifically

• The theme editor. Covered above, and it is the change that generates the most internal friction, usually about four months in.
• Most apps’ front-end components. Apps that inject storefront code, which is most of the interesting ones, do not work against a custom storefront. Their APIs often still do, so the functionality is available but you are rebuilding the interface.
• Shopify’s ongoing storefront work. Performance improvements and new storefront features land in themes. On a custom storefront you implement them yourself, or you do not get them.
• The ability to hire quickly. A Shopify theme developer is a common, well-supplied role. A team that can run a production storefront application is a different and smaller market.

When headless genuinely earns it

Notice that two of those three are about your organisation rather than your store. That is the honest summary of the decision: headless is a staffing choice with a technical implementation, not the other way round.

The middle ground, which is where most stores belong

The choice is not binary, and the intermediate options have improved enough that a lot of the historical reasons for going headless no longer apply.

• A custom theme, built from scratch rather than bought, gives far more design control than people assume, while keeping the theme editor.
• Shopify Functions let you write custom logic for discounts, shipping and payment rules in the platform, which used to be a common headless driver.
• Checkout Extensibility on Plus covers most checkout customisation requests without touching the storefront architecture.
• Metaobjects handle structured content natively, which removes a share of the “we need a real CMS” argument.

Work through these before committing. Each one is cheaper, reversible, and does not add a permanent role to your org chart.

How to actually decide

1. Write down the specific thing the theme cannot do. One sentence, concrete. If the answer is a feeling about design quality, the fix is a better custom theme.
2. Check it against Functions, Checkout Extensibility and metaobjects. A good proportion of blockers from two years ago are now platform features.
3. Measure the current storefront. If the argument is speed, get real field data first. Then find out whether apps, images or the theme are responsible.
4. Name the person who owns the storefront in year two. With a name, a budget line and a backup. This question ends more headless projects than any technical analysis.
5. Ask what happens if you stop investing. A theme that nobody touches for a year keeps working and keeps getting platform improvements. A storefront application that nobody touches for a year accumulates dependency and security debt.

If you clear all five, headless is a good decision and you should make it deliberately. If you stall on the fourth, you have learned something more useful than any comparison table.

Related: build or buy is the same trade in general form, replatforming from Magento or WooCommerce covers moving to Shopify in the first place, and what custom software actually costs covers reading the quotes.

We build both, and we will tell you when a custom theme gets you what you want for a fraction of the commitment. If you are weighing this up, describe the thing your storefront cannot currently do and we will tell you whether it needs headless.