Headless Commerce or a Platform Theme

Choosing between headless commerce and a platform theme is an architectural decision, not a design preference. Get it wrong and you're either paying for flexibility you'll never use, or you're fighting your own storefront every time a product requirement changes.

What Does "Headless" Actually Mean in Practice?

A traditional commerce platform — Shopify with a Liquid theme, WooCommerce with a page builder, Magento's default frontend — couples the presentation layer to the backend. The same system that manages your catalogue, pricing and checkout also renders your HTML. Headless decouples those two concerns. Your commerce engine (Shopify Plus, Medusa, Commerce Layer, BigCommerce) exposes APIs, and you build your own frontend independently, usually in Next.js, Nuxt or a similar framework.

The word "headless" gets used loosely. Some people mean a React storefront consuming a Shopify Storefront API. Others mean a fully composable stack where the cart, search, CMS and checkout each come from different vendors, wired together. Those are meaningfully different architectures, and the trade-offs are not the same.

For this post, I'll focus on the more common decision: a custom frontend consuming a commerce platform's API versus using that platform's native theming system.

When Does a Platform Theme Actually Win?

A theme is not a concession. For a lot of businesses, it's the right call.

Shopify's Online Store 2.0 themes are well-optimised. Lighthouse scores above 90 are achievable without custom work. The checkout is PCI DSS Level 1 certified and converts well because Shopify has run more A/B tests on it than most teams will ever run on anything. You get that for free.

The maintenance cost difference is real. A headless storefront means you own the CDN configuration, the caching strategy, the image pipeline, the accessibility implementation and every third-party script integration. A theme offloads most of that to the platform vendor.

Theme constraints become a genuine problem in specific situations:

• You need a non-standard checkout flow (subscriptions with complex upgrade paths, multi-warehouse split shipments, B2B quoting before purchase)
• Your frontend needs to pull data from sources the platform can't model (ERP pricing, custom configurators, real-time inventory from a WMS)
• You're running the same commerce logic across a web app, a mobile app and an in-store kiosk
• Your content and commerce are deeply interleaved, not just a blog bolted alongside a shop

If none of those apply, a theme will ship faster, cost less to maintain and perform comparably to a headless build.

What Are the Real Costs of Going Headless?

Teams underestimate the operational overhead. Here's an honest breakdown:

Area	Theme	Headless
Time to first launch	6–12 weeks typical	16–30 weeks typical
Frontend team required	No (platform handles it)	Yes (React/Next.js capability)
Checkout customisation	Limited (Shopify: Checkout Extensibility only)	Full control (with caveats below)
CDN and caching	Managed by platform	Your responsibility
Platform upgrades	Mostly automatic	API version migrations are manual
Third-party app compatibility	High (most apps inject into Liquid)	Low (most Shopify apps won't work in headless)

The third-party app point deserves more attention. If you're on Shopify, roughly 80% of the App Store's 10,000+ apps are built to inject into Liquid storefronts. Reviews, loyalty, upsells, live chat integrations, all of them expect the standard theme context. Going headless means either replacing those apps with API-first alternatives or building the integrations yourself. That's not a reason to avoid headless, but it's a cost that needs to be in the budget.

Checkout is another ceiling. Shopify does not expose its checkout over the Storefront API for custom rendering. You can use Checkout Extensibility to add UI blocks, but you cannot replace the checkout page with your own. If custom checkout is a hard requirement, you're looking at Shopify Plus with advanced configurations, or a different platform like Commerce Layer or Medusa where you own the checkout flow entirely.

How Should You Structure a Headless Commerce Stack?

If you've decided headless is right, the composition choices matter more than the framework.

Frontend Framework

Next.js 14 with the App Router is the current standard. It gives you React Server Components for low-JS pages, good static generation support, and a deployment target in Vercel or self-hosted on a Node runtime. Nuxt 3 is a reasonable alternative if your team is Vue-native. Avoid building a single-page application without server rendering; the SEO penalty is real and takes months to recover from.

Commerce API Layer

Shopify's Storefront API (GraphQL) is stable and well-documented. Bigcommerce's GraphQL Storefront API is comparable. If you want platform independence, Medusa v2 is open-source, self-hostable, and has a cleaner data model than most commercial alternatives. Commerce Layer is worth considering for multi-currency, multi-market setups where pricing logic is complex.

Search and Discovery

Your platform's native search will not perform well at scale. Algolia with InstantSearch, or Typesense for a self-hosted option, gives you sub-50ms search response times and lets you control ranking logic. Both have React component libraries that integrate cleanly with a Next.js frontend.

Content

A headless CMS is not optional in a headless commerce stack if content and commerce are interleaved. Contentful, Sanity and Storyblok all have good commerce integration stories. Sanity's GROQ query language is particularly useful for constructing complex content-commerce queries without multiple API round-trips.

What Should You Actually Build vs. Buy?

This is where most decisions go wrong. Teams either build too much or buy components that don't compose well.

Build custom when:

• The logic is a genuine differentiator (complex pricing rules, custom product configurators, domain-specific recommendation systems)
• No off-the-shelf solution fits without significant workarounds

Buy (or use platform-native) when:

• The problem is solved and commodity (payments, tax calculation, email, fraud detection)
• The maintenance burden of ownership outweighs the customisation benefit

Tax calculation is a good example. Building your own tax engine is almost never justified. Avalara or TaxJar via API is accurate, handles jurisdiction complexity and costs a fraction of what in-house maintenance would. Payment processing is similar: Stripe's integration is thorough enough that building around it rather than on top of it is almost always the right call.

Conclusion

The decision comes down to two questions: how much does your frontend need to diverge from what the platform gives you, and does your team have the capacity to own that divergence long-term?

If you're genuinely constrained by a platform theme and have frontend engineering capacity, headless is the right move. If you're considering headless because it sounds modern, the theme will almost certainly serve you better for the next two years.

A practical next step: map out your checkout flow, your content integration requirements and your third-party app dependencies before committing either way. Those three areas will tell you more than any benchmark or case study.

---

FAQ

Is headless commerce faster than a platform theme? Not automatically. A well-optimised theme on Shopify can match a headless Next.js storefront on Lighthouse scores. Headless gives you more control over performance tuning, but it also gives you more ways to break it. The outcome depends entirely on implementation quality, not the architecture itself.

Can you go headless on Shopify without losing checkout functionality? You can go headless on Shopify, but you cannot fully replace the checkout. Shopify's checkout is not exposed for custom rendering. Checkout Extensibility allows UI additions, but the underlying flow remains Shopify's. If full checkout control is a requirement, Medusa or Commerce Layer are more appropriate platforms.

How long does a headless commerce build typically take? A minimum viable storefront consuming a Shopify or BigCommerce API, with proper SSR, search integration and a headless CMS, typically takes 16 to 24 weeks with a focused team. Projects with complex integrations or custom checkout logic run longer. Factoring in content migration and QA, 30 weeks is a realistic ceiling for a full launch.

What's the biggest maintenance risk with a headless approach? API version deprecation. Shopify, for example, releases new API versions quarterly and deprecates old ones on a rolling 12-month cycle. A headless frontend that doesn't track these migrations will break. This is a concrete operational cost that themes largely avoid because the platform handles it internally.

When is a platform theme the wrong choice regardless of simplicity? When you need the same commerce logic on multiple surfaces simultaneously, a theme breaks down. If your web storefront, iOS app and in-store kiosk all need to share cart state, pricing rules and inventory availability, a headless API-first approach is the only architecture that makes that work cleanly without duplicating business logic across systems.

Have a project in mind? Contact Sodio Technologies to discuss your requirements and explore the right technology solution for your business.