Should You Go Headless? Wrong Question.

Everyone asks “should we go headless?” Wrong question. The right one is what your store actually looks like, because the technology decision follows from that, not the other way around.

I’ve built headless Shopify storefronts with Remix and GraphQL. Here’s the honest framework I use before recommending it to anyone.

Headless earns its cost when

SKUs are simple and straightforward, without a sprawling variant matrix. Product pages follow one clean template instead of a dozen bespoke layouts. The UX requirement is genuinely impossible to achieve in native Shopify, not just inconvenient. There’s a dedicated engineering team who will actually maintain it after launch, not just build it and move on. And performance at scale is non-negotiable in a way that native theming can’t reliably guarantee.

It gets expensive when

Marketing updates content two or three times a week and every one of those updates now has to go through a developer or a second content system. The product catalog is complex, with heavy variants, rich descriptions, and comparison tables that don’t map cleanly onto a headless data model. The team is small or shared across other projects and won’t have the bandwidth to maintain a second system. And now there are two systems, Shopify and a CMS, that both need to stay in sync, which is its own ongoing maintenance cost nobody budgets for upfront.

The actual decision

Simple SKUs, a clean UX requirement, and a strong dedicated team: headless earns its cost.

Complex content, fast-moving marketing, and a lean team: native Shopify 2.0 with solid architecture gets you further, faster, and with less to maintain.

The technology isn’t the decision. The store, and the team behind it, is.