# Headless Commerce: Architecture, Platforms, and Cost **URL:** https://mettevo.com/blog/article/headless-commerce **Published:** 2026-09-25 **Updated:** 2026-09-25 **Author:** Oleg Silin **Category:** Blog | Mettevo > Explore headless commerce architecture, leading platforms, key benefits, and costs to understand how a headless approach can support flexible, scalable ecommerce growth. ![Headless Commerce](https://stage.mettevo.com/wp-content/uploads/2026/09/Professionals_viewing_tablet_in_…_20260925103719.jpg) --- Headless commerce is an architecture that separates the storefront customers see from the commerce backend that manages catalog, cart, checkout, and orders, connecting the two through APIs (application programming interfaces). A team can rebuild the frontend in Next.js or Remix without touching order logic. It typically pays off only once a store has the engineering budget to maintain that separation. ## TL;DR - Headless commerce splits the storefront from the commerce backend and connects them with APIs, so the frontend can change without touching checkout or catalog logic. - No platform in this guide publishes a public price for its top headless tier. commercetools quotes custom deals only, and BigCommerce's top plan starts at "custom" above its published $299-a-month mid tier, per each vendor's own pricing page, checked September 14, 2026. - Google renders JavaScript pages in a separate queued step before indexing them, and that step alone "can take longer" than a few seconds, per Google Search Central's documentation. A themed storefront never depends on that step. A headless one always does. - A crawl of all 60 indexable pages on mettevo.com, run August 27, 2026, found WordPress and Next.js signals present on every single page at once, a small but real example of the hybrid setups this guide describes. - Nobody publishes a revenue floor for it, because the number depends on local engineering cost rather than traffic. This guide gives the calculation instead of a guess. ## What Is Headless Commerce? Headless commerce describes any setup where the storefront, the pages a shopper sees, is built and deployed separately from the commerce engine that holds catalog and order data. The two sides talk only through APIs. A monolithic platform, such as a stock Shopify theme or a WooCommerce site on WordPress, ships both halves as one connected system. Change the backend, and the storefront usually has to be touched too. Headless removes that coupling, which is also why it needs its own engineering process instead of inheriting the platform's. Headless commerce is not the same thing as a headless CMS (content management system). The commerce engine owns catalog, cart, and checkout. A headless CMS typically owns marketing pages and blog content instead. Many headless storefronts run both at once: a commerce API for transactions and a separate content API feeding the same Next.js frontend. A related term is composable commerce. The [MACH Alliance](https://machalliance.org/the-mach-manifesto) advocates for technology that is "microservices-based, API-first, cloud-native SaaS, and headless," the four principles its name stands for. Headless is one of them, so a stack built to the full set is headless by construction. Composable commerce is the broader idea sitting on top of those principles: assembling the backend itself from interchangeable best-of-breed services instead of buying one vendor's bundled suite. Not every headless stack is composable: a single vendor can sell one monolithic backend behind a headless frontend, which solves the coupling problem but not the lock-in one. ## Headless Commerce Architecture, Layer by Layer A working headless commerce stack is rarely two pieces. In practice it is five layers, each with its own vendor choices and its own seam to maintain. 1. **Commerce engine.** Holds the catalog, cart and order records, and exposes them through an API: Shopify's Storefront API, BigCommerce's Open APIs, commercetools' Composable Commerce API. Medusa's engine is API-first by default. 2. **Content layer, optional.** A separate headless CMS handles marketing pages and blog content not tied to a product record. Stores with little editorial content skip this layer. 3. **Frontend and rendering layer.** A framework, usually Next.js or Remix, fetches from those APIs and decides how each page renders: SSR (server-side rendering) per request, or SSG (static site generation) at build time. Shopify's own [Hydrogen framework](https://hydrogen.shopify.dev/) is "built on Remix," per Shopify's documentation. 4. **Hosting and edge layer.** Where the rendered frontend runs. Shopify's Oxygen hosting claims "300+ points of presence around the globe, hitting 95% of the internet in under 50ms." Outside Shopify, Vercel and Netlify fill the same role. 5. **Integration layer.** Search and personalization tools plug into the commerce engine and the frontend through their own APIs. Each one can break independently of the rest. Every layer above can be swapped without touching the others. That is the architectural promise, and also the practical cost. A monolith collapses the list to one layer, maintained by whoever built the platform. ## Which Platforms Support Headless Commerce? Most commerce platforms sold today claim some form of headless support. What differs is where real API access sits in the pricing tiers, and whether a price is published at all.  **Platform** **Frontend approach** **Where headless access sits** [Shopify](https://www.shopify.com/pricing) (Hydrogen + Oxygen) Open-source Hydrogen framework, built on Remix; Oxygen edge hosting included Oxygen hosting is free "on all Shopify plans, except Starter" [BigCommerce](https://www.bigcommerce.com/pricing/) ([Catalyst](https://www.catalyst.dev/)) Catalyst: open-source Next.js and React Server Components storefront, hosted on GitHub Open APIs ship on every plan; Catalyst requires a BigCommerce store [commercetools](https://www.commercetools.com/pricing) Bring-your-own frontend against a Composable Commerce API Sales-assisted only, no self-serve published tier [Medusa](https://medusajs.com/pricing/) Open-source Node.js commerce engine, API-first by default Headless from the first line of code, no separate unlock For stores already committed to Shopify, the real question is rarely whether Hydrogen exists. It is whether the catalog and team are ready for it. That scoping work is exactly where [Mettevo's Shopify development](https://mettevo.com/web-development/shopify-development) engagements start, before any decision about a custom frontend gets made. ## What Are the Benefits of Headless Commerce That Actually Hold Up? Three benefits survive contact with a real build. Release independence is the biggest: the frontend and backend deploy separately, so a marketing team can ship a landing page redesign the same week engineering ships a checkout fix. Channel reuse is second: one commerce engine can serve a website and a native app through the same API, instead of maintaining catalog logic twice over. Rendering control is third: a team can choose SSR or SSG per route, instead of accepting whatever a theme engine outputs by default. Speed is the benefit vendors lead with, and it is the one most often overclaimed. Headless does not make a page fast. It makes page speed a decision the team gets to make, rather than one the platform makes for them. Hitting [Google's Core Web Vitals thresholds](https://web.dev/articles/vitals) still takes the same engineering effort headless promised to remove. Google measures three of them at the 75th percentile of page loads: - LCP (Largest Contentful Paint): 2.5 seconds or less. - INP (Interaction to Next Paint): 200 milliseconds or less. - CLS (Cumulative Layout Shift): 0.1 or less. A themed platform ships tuned to hit those numbers already. A custom Next.js or Remix build starts at zero and has to earn them again, template by template. ## How Much Does Headless Commerce Cost? The SEO Bill Nobody Itemizes Every vendor pricing page answers a narrower question than the one a buyer actually has. The subscription or license fee is rarely the largest cost of going headless. The largest recurring cost is engineering time to keep the frontend itself running: - Framework and dependency upgrades. - Monitoring and error tracking. - Rebuilding whatever the platform used to provide for free, page by page. A monolith bundles that work into the subscription. A headless build turns it into a line item the store now owns directly, for as long as the storefront exists. Search engine optimization work multiplies inside that line item. A themed platform ships canonical tags, sitemaps and structured data by default. A custom frontend rebuilds each of them and has to get them right the first time. That matters because [Google Search Central's documentation](https://developers.google.com/search/docs/crawling-indexing/javascript/javascript-seo-basics) describes crawling, rendering, and indexing as separate queued steps for JavaScript pages, and notes that rendering alone "can take longer" than a few seconds. A themed storefront never has to clear that step. A headless one clears it for every page, every time content changes. That dependency is not hypothetical. A crawl of mettevo.com covering all 60 indexable pages on August 27, 2026 found WordPress and Next.js signals on every single page at once: a hybrid render path, not a clean monolith or a clean headless build. That is one property and one snapshot, and no benchmark for how common hybrid setups are elsewhere. It is one concrete example that "headless or not" is rarely the binary vendor pitches present. None of the platforms compared above publish a revenue number where headless starts paying for itself, and this guide will not invent one either. No client dataset exists that would make a single dollar figure honest across industries and local dev rates. What can be stated is the calculation to run instead: compare the fully loaded monthly cost of the frontend engineering retainer against the incremental margin the migration is realistically expected to add. Break that margin into four inputs: - Conversion lift the new frontend is expected to produce, as a percentage. - Average order value, in dollars. - Gross margin, as a percentage. - Monthly order volume. If the resulting monthly margin does not clear the retainer most months, the monolith remains the right answer, regardless of how well the headless build is executed. The vendor pricing ladders above cut against the simple reading. Shopify and BigCommerce both hand headless access to their entry plans: Oxygen hosting for Hydrogen ships free on every Shopify plan except Starter, and BigCommerce's Open APIs and Catalyst work on any BigCommerce store. The platform fee is not the gate. The engineering retainer is. A store weighing a $29-a-month plan can go headless on either platform tomorrow. What it cannot do is absorb the frontend it would then own. For scale, [the U.S. Census Bureau's Quarterly Retail E-Commerce Sales report](https://www.census.gov/retail/mrts/www/data/pdf/ec_current.pdf) for the second quarter of 2026, released August 18, 2026, put e-commerce at 17.1% of total U.S. retail sales that quarter. Most retail revenue is still not online at all. ## Is Headless Commerce Worth It for a Small Store? When a Monolith Is the Right Answer For most stores below that engineering-retainer breakeven, no. A monolith, whether a themed Shopify or BigCommerce store, or WooCommerce on WordPress, already ships the technical SEO defaults a headless build has to reconstruct from scratch. Choosing headless before the team, traffic, or catalog justifies it adds the maintenance cost described above without removing anything the themed store was actually failing at. A monolith is very likely still the right call when: - No engineer on staff or on retainer maintains the storefront frontend itself, only the platform's existing theme or plugins. - The store sells through one channel, a single website, with no near-term plan for a native app or marketplace feed that would reuse the same commerce backend. - Current speed or conversion problems trace back to theme bloat or too many installed apps, both fixable inside the existing platform without a rebuild. Headless starts to make sense once any of the following is already true, not once it sounds appealing: - A frontend engineering team already exists and is currently blocked by the platform's own templating limits, not by a hypothetical future need. - Multiple channels, such as web and a native app, genuinely need to share one catalog and one cart, rather than duplicating product data across systems. - The platform's own theme, after real optimization work, still cannot clear Core Web Vitals thresholds at the store's actual traffic and catalog size. For stores still weighing two monolithic platforms against each other, rather than headless against anything, that is a separate and earlier decision. [Mettevo's WooCommerce vs Shopify comparison](https://mettevo.com/blog/article/woo-commerce-vs-shopify) covers that choice directly, and resolving it first matters, since the platform underneath still shapes what the commerce engine layer looks like later. ## FAQ ### Is headless commerce the same as a progressive web app? No. A PWA (progressive web app) is a set of browser capabilities, offline caching, installability, and push notifications, that any frontend can add regardless of what powers it. Headless commerce describes a backend and frontend split, not a browser feature set. A headless storefront can be built as a PWA, and plenty are not; a themed monolith can add PWA features too. ### Do I need a headless CMS and a headless commerce platform separately? Usually yes, if the store publishes much editorial content. The commerce platform owns catalog, cart, and checkout. A headless CMS owns blog posts, landing pages, and marketing copy that are not tied to a specific product record. Both connect to the same frontend through their own separate APIs, and neither one substitutes for the other. ### Can I add headless commerce on top of WooCommerce? Yes. WooCommerce ships a REST (representational state transfer) API that "lets you read and write various parts of WooCommerce data such as orders, products, coupons, customers, and shipping zones," according to [WooCommerce's own developer documentation](https://developer.woocommerce.com/docs/apis/). A separate Next.js or Remix frontend can call that API directly, which makes WooCommerce a workable, if unofficial, headless backend. ### What is composable commerce, and is it the same as headless commerce? Not quite. Headless only describes decoupling the frontend from the backend. Composable commerce means assembling the backend itself from interchangeable best-of-breed services instead of one vendor's bundled suite, usually following the four principles the MACH Alliance stands for: microservices-based, API-first, cloud-native SaaS, and headless. Because headless is one of those four, a stack built to the full set is headless by construction. Not every headless stack is composable.