Shopify theme or headless storefront?

A commercial question in technical clothing

Almost every headless project we have reviewed was started for one of two reasons: the site felt slow, or the team felt limited by the theme. Both are real problems, and neither is automatically solved by decoupling the frontend. A slow site is usually slow because of scripts and images. A limiting theme is usually limiting because it was built without a content model.

The questions that actually decide the outcome are less exciting: how often do non-developers need to change pages, how many people can maintain a custom frontend, and who is responsible when a dependency needs updating during the Christmas season.

What a modern theme covers today

The gap between themes and custom frontends has narrowed considerably. Sections and blocks can be arranged on every template, app blocks let third-party functionality be placed without touching code, and structured content can be modelled with metafields and metaobjects rather than being pasted into rich text.

Internationalisation, multiple currencies and market-specific content are handled by the platform. Checkout can be extended in defined places. The result: editorial teams can work without a deployment, and most feature requests become configuration rather than development.

When headless genuinely pays off

There are clear cases, and they have one thing in common: the storefront is not the only thing being built.

• Editorial commerce with a real CMS workflow. Magazine formats, long-form content, complex publishing rules and an editorial team that already works in a dedicated system.
• Several brands or markets on one codebase. When the UX differs substantially per brand but the logic should stay shared, a custom frontend can be cheaper than five diverging themes.
• Interactions the platform does not model. Configurators, quoting flows, portal-like B2B areas or deep integrations with an existing application landscape.
• An existing frontend team. Not a freelancer for the launch — a team that will still be there for maintenance, dependency updates and the next redesign.

The costs that rarely make it into the plan

The app ecosystem stops being plug-and-play. Every app that renders on the storefront needs its own implementation, and app updates become development tickets. That is manageable when planned, and painful when discovered after launch.

The editing workflow has to be replaced. Whatever the theme editor did — arranging sections, scheduling a campaign banner, swapping a hero image — now needs an equivalent in the CMS, or it turns into a developer request.

And there is the permanent side: hosting, build pipeline, monitoring, dependency updates, plus the fact that knowledge concentrates in very few heads. Ask early who operates this in two years, and what happens if that person leaves.

Performance is a discipline, not an architecture

A custom frontend with five marketing tags, three chat widgets and unoptimised hero images is slower than a disciplined theme. The levers that actually move Core Web Vitals are the same in both worlds: how many third-party scripts load, how images are served, how fonts are loaded, how much work happens before the first paint.

We build our own sites as static pages with inlined critical CSS and no client-side framework, because that is the cheapest way to keep scores at the top. The point is not the stack — it is that every additional script has to justify itself.

The fastest shop is not the one with the most modern architecture. It is the one with the fewest scripts.

Five questions that carry the decision

Answer these honestly before comparing technologies:

• How often do non-developers change pages? Weekly campaign changes without a deployment are an argument for the theme; a quarterly release cycle is not.
• Who maintains the frontend in two years? A named team, not a plan. Custom frontends fail quietly when the person who built them moves on.
• Which apps are business-critical? List them and check what each one costs to rebuild. That list is often the whole answer.
• What is genuinely impossible in a theme? Write it down concretely. "More freedom" is not a requirement; a configurator with 200 variants is.
• What is the budget after launch? A custom storefront needs a maintenance budget every year, not only a project budget once.

The middle path that gets overlooked

It is not a binary choice. A theme can be extended with custom app blocks and a private app for the parts that really are specific, while everything standard stays on the platform. A single route — a configurator, a landing area, a B2B portal — can run as a separate application next to the shop.

That path keeps the editorial workflow, keeps the app ecosystem, and puts the development budget exactly where it creates a difference. In most projects it is also the decision that can be reversed later, which is worth more than it sounds.