Ecommerce Development · focused work
Headless storefront development
A headless build separates the storefront from the commerce platform. The platform keeps products, inventory, orders and payment. A separate application renders every page a shopper sees. It buys control over structure, speed and content modelling, and it gives up the convenience of a theme and the ecosystem of apps that plug straight into one.
This is the right work if
- The theme is fighting the design and every new section arrives as a workaround
- Editorial content and commerce live in two systems and shoppers can tell where the seam is
- Page performance is capped by the theme and by scripts that cannot be removed from it
- One catalog has to serve several storefronts, markets or brands from a shared frontend
- There is a team or a budget in place to own an application after it launches
What it is
What a headless build involves
The build is an application: a frontend framework, hosting, a data layer that queries the commerce API for products, collections, cart and customer, and a content system for editorial and merchandising. Around that sit the decisions that decide whether it succeeds. Which templates render on the server and cache, how that cache is invalidated when a price or a stock level changes, where the cart lives, and how the shopper is handed to checkout, which normally stays with the platform so payment and compliance stay with it too.
The part stores underestimate is everything a theme provided at no cost. Sitemaps, canonical rules, redirects, structured data, analytics and consent, search and filtering, account pages, review display, subscription flows and loyalty all have to be rebuilt or reconnected through an API. Any app that worked by injecting itself into a theme will not carry over. And a headless storefront is software that keeps existing: it needs a release pipeline, preview environments, monitoring and someone whose job includes updating its dependencies. That ongoing ownership belongs in the decision, not in the surprise after launch.
How it is done
The work, in order
What changes
- The storefront is shaped by the build rather than by what a theme permits
- Content and commerce arrive on the page from one composed source
- Performance is set deliberately instead of by whatever scripts accumulated
- New markets, brands or storefronts reuse the same frontend and data layer
Draw the line between platform and frontend
Write down what stays on the commerce platform: checkout, payments, tax, inventory, orders and customer records. Everything the frontend only reads is listed separately, so nobody later builds a second copy of a price or a stock level in the new application.
Model data and content together
Define the queries for product, collection, cart and customer, then design the content model for the parts a merchandiser edits. Give every field one owner. The commonest headless defect is a field maintained in both the platform and the content system that slowly stops agreeing.
Choose rendering per template
Category and product pages render on the server and cache, with revalidation triggered when price, stock or content changes. Cart and account render for the individual. Getting this wrong shows up as either stale prices or a storefront that is slower than the theme it replaced.
Rebuild the storefront services
Search and filtering, sitemaps, canonical and redirect rules, structured data, analytics and consent, and replacements for the theme apps the store relied on. Each one is scoped as its own piece of work rather than assumed to come with the framework.
Keep the URLs or map them
Preserve the existing URL structure wherever the new stack allows it. Where a path has to change, map every affected URL to a single redirect and test the map against a crawl of the live site before launch rather than after.
Set up ownership before launch day
Deploy pipeline, preview environments for content changes, error and uptime monitoring, performance budgets checked on release, and a schedule for dependency updates. Agree who responds when something breaks at the weekend while the store is still taking orders.
Platform notes
Shopify
The Storefront API serves the frontend while checkout stays hosted by Shopify, which keeps payment compliance with the platform; theme apps do not carry across and each one needs an API-based replacement or a decision to drop it.
BigCommerce
A storefront API serves product and cart data and checkout can be embedded on the store's own domain, so the split between what the frontend renders and what the platform handles can be drawn in more than one place.
Does going headless make a store rank better?
Not by itself. It removes constraints, so the things that do affect rankings become possible: server-rendered pages, control over URLs and markup, and speed that is not dictated by injected scripts. A headless build that renders in the browser and ships a large bundle can rank worse than the theme it replaced.
What happens to the apps installed on the current theme?
Any app that works by adding code to the theme stops working, because there is no theme. Apps that expose an API can be reconnected, and the rest need a replacement or a decision to live without them. Listing them and their cost is part of scoping the project, not a task for after launch.
Can checkout be customised in a headless build?
The frontend controls everything up to checkout. What happens inside checkout still follows the platform's rules, which usually means extension points and configuration rather than free layout, and on some platforms the deeper options are tied to a higher plan. Confirm what the specific plan allows before promising a flow.
When is a theme still the better answer?
When the store's needs are met by a theme with a modest number of apps, when there is no team to own an application afterwards, or when the pressing problems are merchandising and conversion rather than structure. A well-built theme with disciplined app use outperforms a neglected headless storefront.
Related work and answers
Find the leak.
A free Growth Analysis ranks what your store should fix first, by revenue at stake.