Choosing a headless commerce development company on its architecture calls

Three different architectures hide behind the word headless, and two quotes can only be compared once you know which one each prices. A headless frontend puts a new storefront, usually Next.js, on the WooCommerce backend you already run, and products, orders and plugins stay where they are. A composable build adds separate services around it, such as Algolia for search, Sanity or Contentful for content, or a dedicated promotions engine, each with its own contract and its own API. A replatform replaces the backend too, towards Shopify with Hydrogen, BigCommerce or commercetools, and moves every order, customer and integration with it. For a store whose complaint is speed, composable is the worse buy: each added vendor is another monthly bill and another API that can fail at checkout, and the speed came from the frontend alone. An agency that recommends the largest of the three before asking what is actually broken is selling, not scoping.

WooCommerce offers three realistic data layers. The Store API (wc/store/v1) is public by design, made for cart and checkout calls from a browser. The REST API (wc/v3) is another thing entirely: the admin interface, whose consumer keys can create orders, issue refunds and change prices. WPGraphQL plus WooGraphQL returns exactly the fields a page renders. A sensible architecture often mixes them: GraphQL or REST on the server for catalog pages, the Store API for the cart. The answer that should end the conversation is wc/v3 keys called from the shopper's browser, because anyone who opens developer tools can copy a key that edits the store. Ask, too, how SEO metadata crosses the gap. Yoast already exposes its head tags through the REST API as yoast_head_json, and a team planning to rebuild titles and canonicals by hand in the frontend has not done this many times.

Headless storefronts are fast because most pages are built ahead of time and served from a CDN, which makes every one of them a copy that can go stale. So ask what happens when someone edits a price in WooCommerce. The answer you want is on-demand revalidation: a WooCommerce webhook on product.updated calls the storefront, and Next.js rebuilds that product page and the category pages listing it within seconds, through revalidateTag or revalidatePath. A timer alone, rebuilding everything every hour, is the weaker design. Its cost shows on the night a sale ends at midnight and the old price stays on the page until the next scheduled rebuild. Stock follows the same logic with one difference worth hearing them name unprompted: the cart and checkout read live from WooCommerce on every request, so a stale page can mislead a shopper but cannot charge the wrong price.

A headless store runs on two hosts: WordPress and WooCommerce on PHP hosting as before, and the storefront on Vercel, Netlify or a Node server. Ask which one the agency proposes and why, then ask whose account it will be created under. The account belongs to the store, with the agency invited as a team member. A storefront deployed from the agency's own Vercel team is a store that can be switched off in a billing dispute. Get the expected monthly running cost for both hosts in writing, at today's traffic and at three times it, because usage-priced frontend hosting scales with bandwidth and function calls in a way a flat WordPress plan does not. Our builds start at $1,999 for a straightforward setup, and the headless WooCommerce cost breakdown separates what the build costs from what running it costs each month.

Owning the repository is the easy half. The harder half is what that repository depends on. Next.js is MIT-licensed, and a storefront built on it with open-source packages can be cloned, built and deployed by any competent developer holding the store's own accounts. Some agencies build on a proprietary accelerator or a frontend platform licensed per year. That can be a legitimate product, but it is a dependency that outlives the project, and its license fee belongs in the running-cost answer above. The test is concrete: ask for a README that takes a new developer from a fresh clone to a local build, with every environment variable listed and explained. If a stranger cannot get from clone to running storefront in an afternoon, the code is yours on paper only.

• Repository in the store's GitHub organization from the first commit
• No paid accelerator or runtime license needed to build or deploy
• Every environment variable listed with what it does
• A fresh clone builds locally by following the README alone

Checkout is where headless agencies differ most, and their default shows how they weigh risk. A hybrid approach keeps WooCommerce's own checkout behind the new storefront, so payment gateways, tax plugins and order emails keep working unchanged. A fully custom checkout looks cleaner and takes far longer to get right, because every gateway, tax rule and edge case in order creation has to be rebuilt and retested. If your gateways include Klarna, Affirm or anything with a hosted redirect step, a custom checkout is a separate project with its own price. Be wary of an agency that proposes custom before it has asked which gateways you use; hybrid checkout describes the handoff we default to.

Two migration questions sort experienced headless teams from the rest. First, which of your plugins survive. Anything that only changes WooCommerce data keeps working; anything that renders its own frontend output, such as product add-on fields, wishlists, page-builder widgets or review carousels, has to be rebuilt in the storefront or dropped. Expect a two-column list from the audit rather than a promise to handle it, and plugin compatibility for headless WooCommerce shows what that list usually contains. Second, what happens to organic traffic: a redirect map for every URL that changes, metadata and structured data checked template by template, and coverage watched in Search Console for the weeks after launch. A store with real organic revenue should not accept a headless proposal that never mentions redirects.

We build Next.js storefronts on WooCommerce backends, run the audits that decide whether that is warranted, and carry the migration risk that comes with it. We do not manage advertising accounts, and we do not take projects where hosting, images or a plugin cleanup would deliver most of the win; you will hear that from the free audit before there is a proposal. A small store on a well-hosted, well-maintained theme rarely needs headless at all, and telling it so is part of the job.