Headless is not automatically faster
A headless storefront removes theme constraints, and adds a build pipeline, a hosting story, a preview environment and a team that has to maintain all three. It pays off when the front end is genuinely a product. When the real problem is a slow template or a bloated app stack, fixing that is cheaper and faster than replatforming the front end.
PROVEN
RESULTS
TOTAL SALES VS. PREVIOUS PERIOD
Shopify’s headless stack in practice
In a headless setup Shopify stays the commerce engine and the front end becomes your own application. Shopify provides the building blocks. The checkout remains Shopify’s own and is customised through checkout extensibility rather than rebuilt. That limits risk in the payment flow, but it also means part of the customer journey stays outside your front-end code.
Hydrogen: Shopify’s React-based framework for custom storefronts
Oxygen: Shopify’s hosting for Hydrogen, with preview deployments per change
Storefront API: products, collections, cart, search and market context via GraphQL
Customer Account API: login, order history and account data in a headless storefront
Checkout: hosted by Shopify, extended with checkout UI extensions (Plus only in the checkout steps) and Shopify Functions
Metaobjects or a headless CMS for editorial content
Hydrogen is not the only option. A framework such as Next.js on the Storefront API can fit better, for example when your team already works with it or when other applications share the same front end. We choose the stack based on team, content model and hosting requirements, not on preference.
What you take on with headless
A theme does things you only notice once they are gone. In a headless build, the theme editor, many theme-based apps and part of the standard storefront behaviour no longer apply. Each of them needs an alternative, and each alternative is code or a service that someone has to maintain.
Apps built on theme app extensions need an API-based alternative or custom work
Merchandisers work in a CMS or with metaobjects instead of the theme editor
Hydrogen offers utilities for sitemaps, robots.txt and redirects; canonicals, structured data and the rest are built and tested
Analytics, consent and tracking are implemented in the front end and tested again
Markets and languages run through Storefront API context and routing
Previews, deployments and monitoring become part of your release process
Before the build starts, we check every app and integration in the current store against the headless architecture. That way reviews, search, personalisation or loyalty tools do not turn out to be theme-only halfway through the project. The cost of replacing them belongs in the decision, not in the surprises afterwards.
When a theme still wins
Modern Shopify themes are more flexible than their reputation. Sections on every page, metafields and metaobjects for structured content, and theme app extensions cover a large share of what brands ask headless to solve. Speed problems are more often caused by apps, scripts and heavy media than by the theme architecture itself.
If the goal is a distinctive design, a well-built custom theme through Shopify store design is usually faster to launch and cheaper to maintain. If the goal is conversion, CRO on the existing theme gives answers sooner. Headless makes sense when the front end itself is the product, and the team to maintain it is already in place.
Product data can also decide the question. When content from a PIM, a CMS and Shopify has to come together on one page in ways a theme cannot model, headless becomes more attractive. We weigh that against the extra responsibility and put the reasoning in writing.
How a headless build runs
Architecture review. We assess the current store, apps, content sources and team, and document whether headless is justified or whether a theme solves the problem with less risk.
Stack and content model. We choose framework, hosting and CMS, and model content in metaobjects or the CMS, so editors can manage pages without needing a developer for every change.
Design and components. We design a component library around real templates, from product and collection pages to content and account pages, with performance budgets agreed before development starts.
Build and integrations. We build the storefront on the Storefront API and Customer Account API, replace theme-dependent apps and connect search, reviews, CMS and tracking.
SEO and parity testing. We map every URL, redirect and structured data type, test analytics and consent, and compare the new front end with the old store before switching over.
Launch and ownership. We launch with monitoring and a rollback plan. Afterwards we hand over documentation and pipelines, or continue developing and maintaining the storefront with your team.
Headless builds we delivered
Considering headless Shopify?
Tell us what your current storefront cannot do. We give you an honest first view on whether headless pays off, or whether a theme solves it with less risk.
