Headless commerce gets pitched as an upgrade: more flexibility, better performance, total design freedom. Sometimes it is. But headless is a tool, not a trophy, and on Shopify it comes with a real tax — lost features, higher maintenance, and a storefront your team now owns end to end.
This post is a decision framework for the other direction: when a theme is still the right architecture, and how to know that before you’ve spent six months and a six-figure budget discovering it.
Why the default should be the theme
Shopify’s Online Store 2.0 theme architecture (Liquid + JSON templates + sections) is genuinely good at what it does. It gives you:
- Native features for free. Checkout extensions, Shop Pay, market and locale switching, automatic discounts, customer accounts, and the entire app ecosystem work against theme objects and Liquid rendering out of the box. Every one of these is work you’d rebuild in a headless setup.
- An editor merchants understand. The theme editor and sections are the mental model your operators already know. Headless means your team builds — and maintains — whatever editor experience replaces it.
- A performance ceiling that is high enough. A well-built theme with disciplined JavaScript hits Core Web Vitals targets. The headless performance advantage is real but marginal when the theme isn’t the bottleneck — and the bottleneck is usually apps and images, which are the same problem in both architectures.
None of this means “never headless.” It means the burden of proof sits with the headless proposal, not with the theme.
The decision framework
Use these five questions. If you can’t answer most of them in the theme’s favor, stop and reconsider.
1. What is the actual constraint? Write down the thing a theme cannot do — precisely. “We want custom product pages” is not a constraint; the theme can do that. “We need three checkouts in one store” is. If the constraint is a design, a layout, or a page type, a theme handles it. If it’s a rendering environment (native apps, kiosks, third-party surfaces), that’s headless territory.
2. Who owns the storefront tomorrow? If the answer is “a small in-house team that also runs marketing,” the theme wins. Headless frontends are real software: build pipeline, deployments, testing, dependency upgrades, security patches. Budget that cost as a permanent line item, not a one-time migration.
3. What does the editor experience need to be? If merchants must edit pages weekly, the theme editor is a feature. Every headless CMS adds a content-modeling project and an editorial workflow project before anyone edits anything.
4. Which Shopify features are in your roadmap? Checkout extensions (Shopify Functions, checkout UI extensions), Markets, B2B on Shopify, Shopify Subscriptions — all are either theme-native or require custom headless plumbing. Map your roadmap against the headless maturity of each feature before committing.
5. What is the real performance gap? Measure before you architect. Run Lighthouse on your actual storefront and break down the budget: where does LCP time go? If apps or images are eating it, fixing those is cheaper than replacing the architecture. If the theme itself is genuinely unoptimizable (rare), headless has a case.
Score it honestly. One strong “headless” answer — a rendering environment, a roadmap feature themes can’t touch — can justify the move. Three weak answers — “we want more design freedom,” “we heard it’s faster,” “everyone’s doing it” — are a theme decision wearing a headless costume.
The costs headless proposals hide
- Feature lag. When Shopify ships a theme feature, your headless storefront gets it when your team ports it. When Shopify ships an API change, your integration breaks until you fix it. You are now on Shopify’s deprecation treadmill with no vendor buffer.
- Checkout complexity. You can’t fully customize Shopify checkout in headless; you extend it. If your roadmap assumes checkout flexibility, verify against the actual Checkout Extensibility surface before you commit.
- App ecosystem friction. Most apps are built for themes. In headless, you either accept the limitations of theme-embedded apps or build the integrations yourself.
- The editor tax. Someone must build the merchant-facing editing experience. That’s a product, with requirements, QA, and support — for every page type you offer.
A compromise: headless where it pays
The strongest Shopify architectures are often hybrid: a theme for the catalog and checkout-critical flows, headless for the surfaces where it genuinely pays — a native app, a content-heavy campaign experience, a custom product configurator. The Storefront API and Shopify Hydrogen make this coherent: one backend, two renderers, shared cart and customer data.
Treat headless as an architectural option you choose per surface, with the same rigor you’d apply to any technology decision — not as the inevitable destination of a modern store.
When to call in help
If you’re being asked to justify a headless proposal — or to build one when your instinct says the constraint doesn’t hold — a scoped commerce architecture review can pressure-test the decision against your roadmap, your team, and your actual performance data. If the answer is “theme,” that’s a good outcome; it saves the budget for work that moves revenue. Book a Commerce Architecture Review and bring these five questions.