Yuvraj Raulji | Headless Commerce
Headless is sold as a performance upgrade. It is really an organisational one: it decouples the storefront from the commerce release cycle so the front end stops waiting on back-end deployments. If that is not your bottleneck, it will not pay, and most stores asking for it want a faster theme instead.
Quick answer
Headless commerce separates the storefront from the commerce platform. The front end is its own application, usually Next.js, talking to the platform over an API instead of rendering from its templates, while the platform still owns catalogue, pricing, cart and orders. What this buys is independence: the front end gets its own roadmap, release cadence and performance budget. What it costs is a second system, with its own build pipeline, hosting surface and caching strategy that somebody has to own permanently. The business problem headless commerce addresses is organisational, not technical.
Best suited for
- Front-end teams with a roadmap of their own
- More than one consumer of the same catalogue
- Content teams that ship independently of platform releases
- Performance budgets a platform theme cannot meet
Business problems
The symptom as the person with the problem describes it, what it is costing, and where the technology actually helps.
Front-end work is queued behind platform releases
A copy change waits three weeks for a deployment window. This is the problem headless actually solves, and it is an organisational symptom rather than a technical one.
OpportunityDecoupling gives the storefront its own pipeline. The measurable version is how often front-end work waits on a platform release today, and for how long, which is worth counting before committing to anything.
The storefront has to serve more than the store
Web, app, kiosk and marketplace feed all needing the same catalogue and pricing, each currently getting its own partial copy.
OpportunityAt that point the API boundary already exists in practice, and headless makes it explicit rather than inventing it. This is the case where decoupling is close to free, because you were paying for it informally.
Performance has hit the template ceiling
Server-rendered platform templates carrying a decade of accumulated front-end, where every improvement fights the one before it.
OpportunitySometimes the answer is a theme rebuild rather than a decoupling, and it is worth being honest about which. When it genuinely is the ceiling, rendering and caching decided per route is what lifts it.
The content stack and the commerce stack are fighting
Editorial in one system, catalogue in another, and every landing page a negotiation between them.
OpportunityComposable puts them side by side behind one front end rather than nesting one inside the other, so a campaign page stops being a platform deployment.
Approach
Five stages, in this order, on every engagement. Skipping the first one is the most expensive habit in this industry.
Understand
Business modelCustomersProductsOperations
Establish whether the bottleneck is real. How often does front-end work actually wait on a platform release, and for how long. If that number is small, the project is a theme rebuild and should be scoped and priced as one.
Architect
SystemsIntegrationsCustomer journey
Draw the API boundary deliberately: what the storefront owns, what the platform owns, and where cart and session state live. Every ambiguity here becomes a bug that only appears under load, which is the worst time to find it.
Build
TechnologyExperienceFunctionality
Next.js against GraphQL or a Storefront API, with rendering decided per route: static, incremental or server rendered, and the cache invalidation path written down. On a commerce site that is the architecture, not a configuration detail.
Optimize
PerformanceCROSEOCustomer experience
SEO parity as a launch gate. URLs, canonical handling, structured data, pagination and faceted navigation carried across before cutover, not after. A headless launch that resets the URL structure is the most expensive way to redesign a site.
Scale
AutomationAIAnalyticsPersonalization
Edge caching and personalisation at the front end, and search that reads from the same API layer. Decoupling makes AI retrieval easier to add, because the boundary it needs already exists and is documented.
Capabilities
Front end
- Next.js and React
- Rendering strategy per route
- Design system
- Edge caching
- Core Web Vitals
API layer
- GraphQL
- Storefront API
- REST
- BFF patterns
- Schema versioning
Commerce backend
- Magento with PWA Studio
- Shopify with Hydrogen
- Cart and session
- Pricing and promotions
Composable
- Headless CMS
- Search service
- Payments
- Personalisation
- CDN
Operations
- Build pipelines
- Preview environments
- Observability
- Cache invalidation
AI and technology
What each application does, how it works, where the value is, where a person still reviews it, and what it will not do.
Retrieval at the API layer
- What it does
- Semantic search and recommendations served through the same boundary the storefront already uses.
- How it works
- A retrieval service reads catalogue and content through the existing API, returns ranked results, and the front end renders them like any other data source.
- Where the value is
- Decoupled architectures make this cheaper to add than monolithic ones, because the integration point is documented and versioned rather than improvised.
- Where a human reviews
- Merchandising rules stay in front of the model, and someone reviews the failing queries.
- What it will not do
- It does not make the catalogue better. Retrieval quality is bounded by product data quality, and that lives behind the API rather than in front of it.
Edge personalisation
- What it does
- Varying what a visitor sees based on context, at the CDN rather than after the page has loaded.
- How it works
- Segment decisions resolved at the edge with the cached shell, so personalisation does not force every request to the origin.
- Where the value is
- Relevance without giving up the cache, which is the trade that usually kills personalisation on a commerce site.
- Where a human reviews
- Someone owns the segment definitions, because a badly drawn segment is worse than no personalisation at all.
- What it will not do
- It cannot personalise what it does not know, and inferring identity from behaviour is the part that goes wrong most visibly in front of customers.
Content and catalogue assembly
- What it does
- Drafting the merchandising content a decoupled front end needs across many landing pages and collections.
- How it works
- Generation against the schema the front end consumes, written into the CMS as drafts rather than published directly.
- Where the value is
- Throughput on campaign and collection pages, which is where composable stacks generate the most manual work.
- Where a human reviews
- Editorial review before publish, every time. The point of composable is that content ships fast, and that is exactly why an unreviewed pipeline is dangerous here.
- What it will not do
- It will produce plausible merchandising copy with no knowledge of what is in stock or on promotion unless it is given that data explicitly.
Architecture
How the pieces sit together, top to bottom. Only technologies actually used appear here.
Customer
Web, app, kiosk or marketplace, all consuming the same catalogue and pricing.
BrowserNative appFeeds
Front end
Its own application with its own release cycle. This independence is the entire product.
Next.jsReactDesign system
Rendering and cache
Static, incremental or server rendered per route, with invalidation designed rather than discovered.
ISREdge cacheCDN
API layer
The contract. Where it is ambiguous, bugs appear under load.
GraphQLStorefront APIRESTBFF
Commerce platform
Still owns catalogue, pricing, cart and orders. Headless does not remove it.
MagentoShopifyPWA StudioHydrogen
Composable services
Content, search and payments as peers rather than nested inside the platform.
Headless CMSSearch servicePayments
AI
Another consumer of the same API boundary, which is why it is cheaper to add here.
RetrievalRecommendationsEdge personalisation
When to use it
Good fit
- The front end has a roadmap of its own, with people assigned to it
- More than one consumer of the same catalogue and pricing
- A content team that needs to ship independently of platform releases
- A performance budget the platform theme cannot meet
- Capacity to own a second deployment surface, permanently
Think twice
- The real request is a faster site, which is usually a theme project
- One team, one storefront, and no queue behind platform releases
- Nobody who will own rendering and cache invalidation after launch
- A launch date that cannot absorb SEO parity work
- A budget that treats the second pipeline as a one-off cost
Comparison
The comparison that matters is against a theme rebuild, not against doing nothing. A rebuild reaches most of the performance ceiling in a fraction of the time and adds no permanent operating cost. Headless is worth the difference only when the coupling between front end and platform is genuinely costing you delivery time, and that is a number you can measure before deciding.
| Criterion | Headless | Platform theme | Theme rebuild |
|---|---|---|---|
| Solves | Release coupling | Nothing, it is the default | Accumulated front-end debt |
| Time to deliver | Months | Immediate | Weeks |
| Ceiling on performance | Highest, if managed | Platform templates | High |
| Ongoing cost | A second pipeline, permanently | None beyond the platform | None beyond the platform |
| Multi-channel | Native | Awkward | Awkward |
| SEO risk at launch | Real, and manageable | None | Low |
| Who must own it | A front-end team | Whoever has the platform | Whoever has the platform |
| AI opportunity | Cheapest to add | Possible | Possible |
Relevant work
A headless storefront and a custom B2B platform, both built over REST and GraphQL boundaries rather than inside a platform theme.
Headless commerce · FashionHeadless fashion storefront
High-performance headless commerce architecture for India’s fastest-growing men’s fashion brand.
HeadlessStorefront APIPerformance
Custom platform · B2BProcurement and approvals platform
Scalable B2B procurement platform streamlining purchase requests and approvals.
B2B workflowsApprovalsIntegrations
Business outcomes
Front-end release cadence
The number the project exists to change: how often the storefront can ship without waiting for a platform deployment. Measure it before, or the result is unarguable afterwards.
Core Web Vitals
Headless makes a fast site possible rather than making a site fast. The gain comes from rendering and caching decisions, and those decisions are what to hold the project to.
SEO parity at cutover
The most valuable outcome of a headless launch is that nothing happens: URLs, canonicals, structured data and pagination survive intact. It is invisible when done well and catastrophic when skipped.
Second-pipeline cost
The honest counterweight. A build pipeline, a hosting surface and a caching strategy, owned permanently. Projects that budget this as a launch cost rather than an operating one are the ones that regret the architecture.
No percentage is quoted on this page. The headless record is real and appears in the work list, but no engagement on it has a published performance measurement, and the honest reason is that headless results are inseparable from the rendering and caching choices made alongside them. A number without those choices attached would not tell you anything transferable.
FAQ
- What is headless commerce?
- An architecture where the storefront is a separate application from the commerce platform, talking to it over an API. The platform keeps catalogue, pricing, cart and orders; the front end owns presentation, rendering and its own release cycle. Composable extends the same idea to content, search and payments as independent services.
- Does headless make a store faster?
- It makes a fast store possible, which is not the same thing. A headless build with an unconsidered rendering strategy is comfortably slower than a well-tuned platform theme. The speed comes from caching and rendering decisions, and most of those are available to you without decoupling at all.
- When is headless commerce worth it?
- When front-end work is genuinely queued behind platform releases, or when more than one channel consumes the same catalogue. Both are measurable before you commit. If neither is true, headless buys an extra deployment surface, an extra failure mode and very little else.
- Headless on Magento or on Shopify?
- Both work. Magento with PWA Studio or a custom GraphQL front end suits complex catalogues and B2B rules; Shopify with the Storefront API or Hydrogen suits brand-owned D2C. Choose the commerce layer on the commerce requirements first, then decouple, never the other way round.
- What does headless cost to run?
- A second build and deploy pipeline, a hosting surface with its own scaling behaviour, and someone who owns the caching strategy. Budget for it permanently rather than as a launch cost, because it does not go away after go-live.
- What is the SEO risk in going headless?
- The cutover. URLs, redirects, canonical handling, structured data, pagination and faceted navigation all have to carry across before launch rather than after it. Treat parity as a launch gate: if it is not verified, the launch waits.
- Is composable the same as headless?
- Headless separates the front end from the commerce platform. Composable goes further and treats content, search, payments and commerce as independent services assembled behind one front end. Composable is a superset, and it multiplies both the flexibility and the number of contracts you now own.
- Can we go headless incrementally?
- Yes, and it is usually the right sequencing. Take one route or one template at a time behind the same domain, with the platform still serving the rest. That keeps each step independently valuable and stops the project becoming a single cutover with no way back.
- How does AI fit into a headless architecture?
- It becomes another consumer of the API boundary that already exists, which is why retrieval and recommendations are cheaper to add on a decoupled stack. The integration point is documented and versioned instead of improvised, and that is most of the work on a monolith.
- Should we go headless just to use Next.js?
- No. Enjoying the framework is a real thing, and it is not an architecture decision. If the team wants a modern front-end toolchain and there is no release coupling to solve, a theme rebuild with a proper build pipeline gets most of the benefit without the permanent second system.
Next step
Let us look at your business model, the systems you already run and where you are trying to get to, before choosing the technology. That conversation is usually shorter than people expect, and it occasionally ends with me saying you do not need the project.