A headless ecommerce platform splits the storefront your shoppers see from the commerce engine that holds catalogue, cart, checkout and order data, connecting the two through an API instead of a shared codebase. That split lets a brand rebuild its front end — a faster product page, a custom checkout step, a native app — without touching the systems that process an order, and it is the reason every platform in this comparison markets itself as “headless” while meaning something structurally different by it.
The pages already ranking for headless ecommerce platform run a feature-grid shape: API count, a “flexibility” score, a pricing tier pulled from a sales call nobody can verify. None of them say what a brand gives up choosing each option, or who should not be evaluating it in the first place. This comparison covers four platforms a scaling brand at $3M–$30M revenue, running Shopify Plus or a paid subscription platform, would realistically shortlist — Shopify Hydrogen, commercetools, BigCommerce’s headless option and Salesforce Commerce Cloud — on pricing model, migration effort and, on every entry, who it is not for.
What Does “Headless” Actually Change for an Operator?
Going headless moves the cost of every storefront change from a platform’s release cycle to your own engineering backlog. A hosted, non-headless storefront ships new checkout features, mobile performance improvements and accessibility fixes on the vendor’s schedule, included in the subscription. A headless storefront ships whatever your team builds, when your team builds it — the platform stops being the bottleneck and your front-end engineering capacity becomes it instead.
That trade only pays off when the thing your team wants to build is something the hosted storefront cannot do: a sub-second product page on a custom framework, a checkout embedded inside a native app, a single commerce engine serving five regional storefronts with different front ends. A brand that wants “a faster site” without a specific front-end requirement the hosted platform blocks is paying the headless tax — the ongoing engineering headcount to run and patch a custom front end — for a problem a theme change or a CDN would have solved.
Which Headless Ecommerce Platforms Should a $3M–$30M Brand Actually Shortlist?
Four platforms cover the realistic range for a brand at this revenue band, from “stay on Shopify’s back end, rebuild only the front end” to “replace the entire commerce engine.” Each entry below states the pricing model rather than a dollar figure, because none of the four publish a fixed rate card at $3M–$30M volume — pricing is negotiated, tiered by GMV, or bundled with an existing plan, and a quoted number from memory would be stale before this page is indexed.
1. Shopify Hydrogen
Hydrogen is Shopify’s own React-based framework for building a custom storefront on top of Shopify’s existing catalogue, cart, checkout and order infrastructure via the Storefront API. It is not a separate commerce engine — it is a way to keep Shopify Plus as the back end while replacing only the presentation layer, deployed on Shopify’s Oxygen hosting or elsewhere.
Pricing model. Hydrogen itself is free and open source; the cost is Shopify Plus’s existing subscription (already published under priceFrom on Pointerflow’s Shopify Plus service pages) plus the engineering time to build and maintain the custom storefront. Oxygen hosting is included with Shopify Plus at published usage tiers rather than billed as a separate line item — confirm current limits on Shopify’s own Hydrogen documentation before committing, since hosting allowances change between platform releases.
Migration effort. Lowest of the four, because there is no data migration — catalogue, customers, orders and checkout stay on Shopify’s systems throughout. The work is entirely front-end: rebuilding every themed page, app-embedded widget and checkout customisation that the current Shopify theme relies on, in React, against the Storefront API’s actual field coverage.
Who this is not for. A brand not already committed to Shopify Plus, since Hydrogen only pays off if you are keeping Shopify’s back end — building Hydrogen and then migrating off Shopify’s commerce engine later means rebuilding the front end a second time against a different API. It also is not for a brand whose current theme and apps already do everything the storefront needs; Hydrogen adds an ongoing engineering headcount for a rebuild with no functional gap to close.
2. commercetools
commercetools is a fully composable, API-first commerce engine with no bundled storefront at all — catalogue, cart, pricing, promotions, order management and checkout are each independent microservices, and every front end, from web to app to voice, is built entirely from scratch against those APIs. It is the platform most often meant when “headless” is used as a synonym for “composable,” and it has no hosted admin theme or checkout to fall back on.
Pricing model. Usage-based and negotiated directly with commercetools’ sales team, typically scaled to order volume, API call volume or a combination of both rather than a flat monthly fee. There is no self-serve published price list; every quote is a sales conversation, which is itself a signal about the buyer commercetools expects — an enterprise procurement process, not a monthly card charge.
Migration effort. Highest of the four. Every piece of commerce logic that a hosted platform provides out of the box — cart persistence, tax calculation, promotion stacking, payment orchestration — has to be either built by your team or wired to a third-party service and integrated. commercetools’ own documentation describes this as assembling a stack from composable building blocks, which is accurate: nothing works until it is built.
Who this is not for. A brand without a standing platform engineering team, because commercetools has no admin UI for a merchandiser to manage a promotion without a developer, and no default checkout to fall back on while a custom one is built. It is also not for a brand that needs to launch or materially change its storefront in under a few months; the assembly time before a first commercetools-powered storefront goes live is measured in engineering quarters, not sprints.
3. BigCommerce headless
BigCommerce’s headless option runs the same commerce back end — catalogue, cart, checkout, order management — that powers its hosted Stencil storefronts, exposed through open GraphQL and REST APIs (including the BigCommerce Catalyst framework for a Next.js-based storefront). It sits between Hydrogen’s “stay on one vendor’s rails” and commercetools’ “build everything,” offering a merchant-facing admin panel alongside full API access.
Pricing model. Tiered by GMV on BigCommerce’s published Enterprise plan structure, the same tiering that applies to its hosted storefronts — headless is a deployment choice within an existing plan, not a separately priced product. Confirm the current GMV thresholds on BigCommerce’s own pricing page, since Enterprise tier boundaries are revised periodically.
Migration effort. Moderate. The commerce engine (products, customers, orders) migrates the way any BigCommerce Enterprise migration does, using BigCommerce’s own import tooling and API, while the storefront is built new against Catalyst or a custom front end. A brand keeps BigCommerce’s merchandising admin throughout, which lowers the retraining cost for a marketing or merchandising team compared with a platform that has no admin at all.
Who this is not for. A brand that specifically wants to avoid vendor lock-in on the commerce engine, since BigCommerce headless still means BigCommerce owns catalogue, cart and checkout logic behind its API — the front end is decoupled, the back end is not. It is also a weaker fit for a brand already deep into Shopify’s app ecosystem; migrating off Shopify Plus to BigCommerce is a full platform migration, not an incremental headless step, regardless of front-end framework.
4. Salesforce Commerce Cloud (headless)
Salesforce Commerce Cloud exposes its catalogue, cart, checkout and order management through the Commerce API and PWA Kit for a fully decoupled, React-based storefront, aimed at enterprise brands already inside the Salesforce ecosystem — Marketing Cloud, Service Cloud, Salesforce CRM — who want a headless front end without leaving Salesforce’s commerce infrastructure.
Pricing model. Revenue-share and negotiated licensing, historically tied to a percentage of GMV processed through the platform plus a platform licence fee, set through Salesforce’s enterprise sales process rather than a published rate card. This is the pricing model most sensitive to negotiated volume commitments among the four, so a quoted figure from any prior year is unreliable.
Migration effort. High, comparable to commercetools for the storefront rebuild, but lower for a brand already running other Salesforce products, since identity, customer data and marketing automation integrations may already exist. A brand with no existing Salesforce footprint takes on both the storefront build and a net-new enterprise vendor relationship at once.
Who this is not for. A brand outside the $3M–$30M band this article targets — Salesforce Commerce Cloud’s sales process, minimum commitments and implementation partner ecosystem are built around enterprise accounts well above this range, and a smaller brand typically finds itself paying for platform capacity and account management it will not use. It is also not for a brand without any existing Salesforce relationship, since the ecosystem integration that justifies its enterprise pricing is the main advantage over commercetools’ more platform-agnostic composability.
How Should You Decide Between a Hosted and a Headless Ecommerce Solution?
Start from the specific front-end capability the hosted storefront cannot deliver, not from “headless” as a category. If a brand cannot name that capability — a checkout step, a page-load target the current theme misses, a cross-channel front end the current platform cannot serve — going headless trades a working, vendor-maintained storefront for an ongoing engineering commitment with no offsetting gain. A named capability then narrows the shortlist quickly: match it against whichever of Hydrogen, commercetools, BigCommerce headless or Salesforce Commerce Cloud already ships the closest thing to it, since building from a near-miss costs less than building from nothing.
Staff before you build. Every headless ecommerce solution above shifts work that a hosted platform used to do for you onto your own team, permanently — not just for the initial build, but for every security patch, framework upgrade and browser-compatibility fix afterward. A brand evaluating headless ecommerce software should staff the ongoing maintenance role before signing anything, because the build is a project with an end date and the maintenance is not.
What Breaks First When a Headless Migration Goes Wrong?
The most common failure is treating the front-end rebuild as the whole project and discovering the commerce logic gap afterward. A promotion rule, a tax exemption, a loyalty-point redemption that the old hosted theme handled invisibly turns out to live nowhere in the new API-first stack, because nobody wrote down that the old platform was doing it. Audit every piece of storefront behaviour the current platform handles for you — not just the visible features, but the checkout validation, the inventory hold logic, the abandoned-cart trigger — before scoping the rebuild, so the gap surfaces in planning instead of in a live cart.
Underestimating checkout is the second most common failure. Checkout carries the most regulatory and payment-compliance surface area of any storefront component — PCI scope, tax jurisdiction logic, fraud screening — and every platform above treats it differently: Hydrogen defers to Shopify’s existing checkout, commercetools requires building or integrating one entirely, BigCommerce and Salesforce sit in between. Confirm which checkout model a candidate platform actually uses before estimating timeline, because “headless” does not tell you whether checkout is rebuilt or reused.
Where a Headless Migration Becomes an Ops Automation Problem
Every headless migration above eventually stops being a front-end project and becomes an operations problem: the workflows that ran invisibly inside a hosted theme — inventory sync, order routing, a promotion rule triggered by a customer tag — have to be rebuilt as explicit automation once the platform stops doing them for free. That rebuild is exactly the gap Pointerflow’s ops automation service exists to close: mapping every manual and semi-automated workflow a current platform hides, before a headless rebuild ships without them.
Sources
Vendor documentation for each platform’s headless architecture is cited inline and listed above; no third-party benchmark or independent pricing figure is quoted. Every pricing statement above describes the billing model each vendor publishes, not a dollar amount, because none of the four publish a fixed rate card at $3M–$30M GMV.