Headless commerce on BigCommerce means replacing the default Stencil storefront theme with a custom frontend, built in React or whatever framework a team chooses, that talks to BigCommerce purely through its GraphQL Storefront API for catalog, cart, and checkout data, while BigCommerce keeps running orders, inventory, and payments in the background exactly as it would otherwise. We don't build that custom frontend. We build the integration layer connecting BigCommerce's backend data to the rest of your business, which has to exist whether the storefront is headless or not.
A standard BigCommerce store runs on Stencil, BigCommerce's own theme engine, rendering pages server-side the traditional way. Going headless means detaching that frontend entirely: a separate application, a Next.js app, a mobile app, whatever a team builds, queries BigCommerce's GraphQL Storefront API for product data, manages cart state through it, and either hands off to BigCommerce's hosted checkout or builds a fully custom one against the Checkout API.
BigCommerce also maintains Catalyst, its own open-source Next.js framework purpose-built for headless BigCommerce storefronts, meant to shortcut a lot of the groundwork a team would otherwise write from scratch connecting a custom frontend to BigCommerce's APIs. It's a starting point, not a requirement; plenty of headless BigCommerce builds use a different stack entirely.
Going headless doesn't reduce the backend integration work a business needs; if anything it often increases it, since Stencil's theme ecosystem includes a lot of app integrations and widgets that a custom frontend has to either rebuild or do without. The accounting sync, the inventory feed, the CRM handoff, all of that still has to connect to BigCommerce's backend regardless of what the shopper-facing frontend looks like.
The decision to go headless is usually driven by a frontend need, more design control, a different performance profile, a unified experience across a mobile app and a website, not by any backend limitation. Confusing the two is a common mistake: a business doesn't need to go headless to fix a slow or manual integration problem, and going headless doesn't fix one on its own either.
Order, inventory, and customer sync built against BigCommerce's own APIs directly, so it keeps working whether the storefront in front of it is the default Stencil theme, a Catalyst build, or something else entirely.
A loyalty widget or a review app that worked automatically through a Stencil theme's app marketplace gets rebuilt as a direct API integration for the custom frontend, instead of quietly disappearing when the storefront goes headless.
Tell us what the old theme handled automatically that the new frontend doesn't, and we'll scope what rebuilding that connection actually takes.
The frontend decision, what framework, what design system, is usually the part that gets the most attention. The backend connections that made the old theme work are the part that actually breaks if nobody plans for them. Headless BigCommerce is just this page's example; n-frames builds the integration layer underneath any frontend, custom or not.
Let's talk →An architecture where the shopping frontend, what a customer actually sees and clicks through, is built separately from the backend commerce platform that handles catalog, cart, checkout, and orders, with the two communicating purely through an API instead of the platform rendering its own pages.
No. A standard BigCommerce store runs on Stencil, its own server-rendered theme engine. Going headless is a deliberate choice to build a separate frontend against BigCommerce's GraphQL Storefront API instead, not something that happens automatically.
An open-source Next.js framework BigCommerce built specifically for headless storefronts, meant to shortcut the groundwork of connecting a custom frontend to BigCommerce's APIs. It's one option for going headless on BigCommerce, not the only one.
Yes, for the custom frontend itself; it's a real application build, not a theme customization. The backend integration work, accounting, inventory, CRM, is a separate project regardless of whether the frontend ends up headless or stays on the default theme.