Shopify vs a headless build: the real decision factors

Shopify versus a headless commerce build gets framed as a technical debate about flexibility and performance, and that framing misses the factor that actually predicts satisfaction two years later: how often the catalog and merchandising change, and who's making those changes day to day.

We've built both, for clients ranging from a single-founder direct-to-consumer brand to a multi-brand retailer with a dedicated merchandising team, and the pattern holds consistently regardless of company size: the technology decision that looks right in a planning meeting and the one that actually holds up two years later are decided by the same underlying question, not by revenue or catalog size.

A retailer whose merchandising team needs to launch new collections, run flash sales, and reorder the homepage weekly needs a platform their non-technical team can operate without filing a developer ticket for every change. Shopify's ecosystem, especially with a well-built Online Store 2.0 theme, is built exactly for that kind of operational independence.

This matters more than it sounds like it should in a planning conversation, because the cost of a headless build's flexibility shows up months after launch, not on day one. A marketing manager who needs a developer to reorder homepage sections for a Friday flash sale is a manager whose flash sale either slips or ships without the changes they wanted, and that friction compounds every single week it exists.

When the buying experience itself is the differentiator (a configurator, a highly custom checkout flow, tight integration with an unusual backend system) Shopify's theme constraints start working against you, and a headless build using Shopify or another platform purely as the commerce backend, with a fully custom Next.js frontend, gives back the control that requires.

We built exactly this for a made-to-order furniture brand where the core product experience was a real-time configurator showing fabric, wood finish, and dimension changes on a 3D render before checkout. No Shopify theme, however customized, could deliver that interaction without fighting the platform's rendering model at every step. Shopify still runs the cart, checkout, and order management underneath, which is the right division of responsibility: use the platform for what it's genuinely good at, and build custom only where the product actually demands it.

Headless builds cost meaningfully more to build and maintain, because you're now responsible for infrastructure and tooling a hosted platform handled for you. We only recommend it when the custom experience is genuinely core to the business, not because it sounds more technically impressive in a pitch. For most retailers, a well-built Shopify theme outperforms a headless build on cost per outcome, even if it's the less exciting answer in a sales conversation.

The concrete numbers help here. A well-built Shopify theme for a mid-size catalog typically runs a fraction of a comparable headless build's initial cost, and the ongoing maintenance gap is even larger, since a headless frontend needs its own hosting, its own monitoring, and a developer on call for anything that breaks, none of which a hosted Shopify theme requires.

There's a middle path that gets underused: Shopify with a heavily customized theme built on the Storefront API for specific high-traffic pages, while keeping the rest of the site on standard Shopify sections. This lets a brand get custom performance and design control exactly where it matters most, the homepage and top product pages, without taking on full headless infrastructure for the entire site.

We recommend this for retailers who have one or two pages carrying a disproportionate share of traffic and conversion value, but whose broader catalog and content pages don't need the same level of custom control. It's a smaller, more defensible investment than going fully headless, and it's reversible in a way a full headless migration usually isn't.

Before deciding between Shopify and headless, we ask a more basic question: has the current platform actually been ruled out through a real attempt to make it work, or is the desire for a rebuild really a proxy for a different frustration, like a poorly built existing theme rather than a limitation of the platform itself. A surprising number of "we need to go headless" conversations resolve once we point out that the actual bottleneck was a badly structured Liquid theme from years ago, not anything inherent to Shopify.

That diagnostic conversation is worth having before committing budget either direction, because the wrong diagnosis leads to the wrong fix: a headless rebuild solves nothing if the actual problem was a theme nobody had properly maintained, and it adds a permanent maintenance burden on top of a problem that a theme rebuild alone would have fixed for a fraction of the cost.

We ask who, by name or by role, would actually be making product changes six months after launch. If the honest answer is a marketing coordinator with no development background, that answer alone usually settles the decision toward Shopify regardless of how interesting the headless option sounds in the room. If the answer is a dedicated product and engineering team who already ships changes to a codebase weekly, headless stops being an infrastructure risk and starts being a natural fit for how the team already works.

It's worth asking this question of the actual team that exists today, not the team a client plans to hire eventually. We've seen clients choose headless anticipating a future engineering hire that took over a year to materialize, during which every routine merchandising change had to be routed through us or another outside developer at an ongoing cost nobody had budgeted for. Build for the team you have, and revisit the decision when the team actually changes, not before, since a platform migration is a much larger project than the one you'd be avoiding by waiting.