Choosing a headless ecommerce platform without buying a category

A headless commerce setup separates the storefront customers load from the system that holds products, orders and payments. The two communicate over an API. That is the entire definition, and it explains why the category is so confusing: almost any commerce backend can be run headless, so the label describes an architecture. It has never described a product. The real question is never "which headless platform" but "which backend, which frontend, and who maintains the seam between them". That seam is the part vendors are quietest about. It is code you own, it breaks when either side ships a major version, and it needs somebody on call the week WooCommerce releases an update.

A hosted platform keeps the backend, and you build a custom frontend against its API. You get managed infrastructure, PCI scope handled and updates you do not run, at the cost of a subscription that often scales with your revenue, platform rules you cannot override and API limits that shape your architecture. Shopify and BigCommerce are the two names most stores weigh here. Shopify's route is Hydrogen, its React framework for the Storefront API, usually hosted on Shopify's own Oxygen, and every order paid through a gateway other than Shopify Payments carries an extra transaction fee, 2% on the Basic plan. BigCommerce ships Catalyst, an open-source Next.js storefront, and moves a store off its Standard plan once online sales pass $50,000 a year. This suits businesses that want modern frontend control without owning operations, and it stops suiting them at the point where a platform rule collides with the business model. Of the two, Shopify is the worse fit for a store that wants to keep its own payment processor, because the fee applies to every order for as long as the store runs. The trade-offs for a WooCommerce store specifically are in headless WooCommerce vs Shopify and headless WooCommerce vs BigCommerce.

• The vendor runs the backend, so you never patch it and never choose when it changes
• The frontend is entirely yours, including the maintenance nobody quotes for
• Growth raises the bill without raising what you consume
• An API quota becomes an architectural constraint, not a technical detail

Commerce, content, search and payments are assembled from separate specialist services, each best-in-class, integrated by your team: commercetools or Elastic Path for commerce, Contentful or Sanity for content, Algolia for search, Stripe or Adyen for payments, in whatever combination the business needs. commercetools publishes no list prices, so the first number arrives in a negotiated contract. It is the right answer at large scale, with multiple regions, catalogs and business units, and it carries the highest integration burden of any option: several vendor relationships, several contracts and an in-house team whose job is keeping the seams working. Businesses adopt this because they have outgrown a single system, not because they wanted more systems.

You self-host a commerce backend (Medusa, Saleor, Sylius, Magento Open Source) and build the frontend against it. Full control, no revenue-based platform fee, and any rule you can express in code. In exchange you own hosting, updates, security and uptime, and the cost of that ownership is a real line item. Nobody rounds it away. This is a good fit for teams with development capacity and unusual requirements, and a poor one for businesses that have nobody to call when a dependency update breaks something on a Friday.

Instead of adopting a new commerce system, you put a custom frontend on the one already holding your catalog, orders and integrations. For the large number of businesses running WooCommerce, this is the option that is usually missing from ranked lists, and it is often the cheapest path to the outcome people actually want: a fast, controllable storefront. The database is never exported, because the storefront reads the same WooCommerce REST API a mobile app would, operations stay untouched, and the project is confined to the layer customers load, and how a headless WooCommerce storefront is built shows that layer piece by piece. It is the wrong category when the backend is the constraint: a selling rule WooCommerce cannot express does not get easier behind a new frontend.

• No data migration, because the backend does not change
• Existing plugins, tax rules and integrations keep working
• Staged rollout, template by template, with a rollback
• The narrowest project that still delivers the speed win

Who maintains this in eighteen months: you, an employee, an agency, nobody? How unusual are your selling rules, honestly (subscriptions, wholesale tiers, configurable products, market-specific pricing), and can the backend you are considering express them without custom code? What does your current backend cost you at your volume, fees and limits included? What is the cost of the migration itself, including the search visibility your existing URLs already have? And what specifically is broken today that headless fixes? If you cannot answer the last one in a sentence, the architecture is not your problem yet.

Poor product data, an offer nobody wants and a store with no traffic look the same in all four categories, and a platform migration copies the first one across row by row. A new architecture also brings no Core Web Vitals win by itself when the build carries the same marketing tags as the old store. The full list of what headless leaves untouched, with the cheaper fixes to try first, is in the headless decision guide. Settle those before comparing vendors.

A platform's pricing page shows the subscription. Your accounts will also show frontend hosting, billed separately from the commerce backend, and developer time that never really ends, since a custom storefront is a codebase whose dependencies keep moving. Every service that used to be a plugin becomes integration work. Then there is the migration, including the redirect and metadata work that protects existing organic revenue. That leaves a clean rule: if your store cannot name a number that headless is supposed to move (checkout completion, mobile LCP, organic revenue on category pages) the honest answer is that headless is the wrong purchase this year, and a faster theme plus better hosting is the right one.

Week one is arithmetic. Write down the specific limitation driving this, then check whether it is a backend limitation or a frontend one. That single distinction eliminates most of the field. Price your current platform at your real volume, per-app costs included. Week two is one quote, for the narrowest option that would fix the named limitation, not for the impressive one. Compare both against doing nothing, which is always a legitimate option and rarely on the table because nobody sells it. If the narrow fix works, take it; the broad rebuild will still be available in a year, when you will know more than you do now.

We build category four: Next.js storefronts on top of the WooCommerce a business already runs, sold as a headless WooCommerce migration from $1,999. That is a genuine bias and you should weigh it. It also means we routinely tell people their problem is hosting, images or a plugin stack and not architecture, because we would rather not sell a project that will not pay back. The do you need headless WooCommerce test exists for exactly that conversation, and the free audit answers it with measurements.