BigCommerce Catalyst and Makeswift vs. a Backend-Agnostic Frontend

BigCommerce has spent the last two years rebuilding its storefront story. Catalyst is the new storefront framework, a Next.js and React foundation that talks to the BigCommerce Storefront GraphQL API. Makeswift, the visual editor BigCommerce acquired in 2024, sits on top as the layer where marketers edit pages without a developer ticket. Together they replace the older Stencil theme approach with something that looks a lot more like modern composable commerce. For a team already committed to BigCommerce as a backend, that is a genuine step forward. The decision worth slowing down for is a different one: both tools are built to work with the BigCommerce backend, and only that backend. This article looks at what that coupling means, and when a backend-agnostic frontend is the better fit.

What Catalyst and Makeswift actually are

Catalyst is BigCommerce's storefront framework. It ships as a Next.js (React) application wired to the Storefront GraphQL API, with a component library and a working reference storefront out of the box. It is the modern successor to Stencil, BigCommerce's older Handlebars-based theme framework, and the path BigCommerce points teams to for headless and composable storefronts today.

Makeswift is a visual page builder. BigCommerce acquired it in 2024 and positioned it as the visual editing layer for Catalyst: marketers compose and edit pages built from React components, without touching code, while developers keep control of the components underneath. If you have followed the wider category, the pattern is familiar. It is the same split between developer-owned components and marketer-owned composition that defines a Frontend Management Platform.

Both are solid. Catalyst is a real improvement over hand-maintained Stencil themes, and Makeswift closes the visual-editing gap that headless setups usually open. The question is not quality. It is coupling.

The coupling question

Catalyst reads its data from the BigCommerce Storefront GraphQL API. Makeswift edits pages inside that same context. That is by design, and for a BigCommerce-committed team it is exactly what you want: tight integration, one vendor, a supported path. The trade-off is that the frontend you build is a BigCommerce frontend. If the backend picture changes later, a subsidiary on a different platform, a B2B unit that needs commercetools, a decision to move off BigCommerce entirely, the Catalyst storefront does not come with you. You rebuild the frontend against the new backend.

A backend-agnostic frontend inverts that relationship. Instead of the storefront reading directly from one backend's API, a Frontend Management Platform sits as its own layer and connects to the backend through a data layer that normalizes product, price, inventory, and order data into a single component schema. BigCommerce can sit behind it today. A different backend can sit behind it in two years, without rebuilding the storefront. We compared the broader set of choices in BigCommerce headless frontend options compared; this piece is specifically about the Catalyst and Makeswift path versus that agnostic layer.

Catalyst plus Makeswift vs. a backend-agnostic frontend

When Catalyst plus Makeswift is the right call

If BigCommerce is your backend and you have no realistic plan to change that, Catalyst plus Makeswift is a reasonable, well-supported choice. You get first-party integration, a vendor-maintained framework, and a visual editor built for it. A capable React team that wants to own the storefront code directly, and is comfortable tracking Catalyst and Next.js upgrades, will be productive quickly. The coupling to BigCommerce is a cost only if your backend might change. If it will not, it is simply the shape of the platform you chose.

When a backend-agnostic frontend makes more sense

The agnostic layer earns its place when the backend is not a settled question. Common signals: you run more than one commerce backend across brands or regions, you are evaluating a backend move but do not want to rebuild the frontend as part of it, or you want to keep the architecture decision reversible. This is the same reason teams decouple frontend modernization from backend replatforming, more on that in BigCommerce replatforming without a frontend rebuild and in alternatives to BigCommerce. With a composable headless frontend delivered as a managed Frontend as a Service layer, framework upgrades, hosting, and security patches are platform work rather than your team's sprint work, and the same storefront runs over whichever backend you connect.

For engineering teams, the practical difference sits in one place: where the backend is named.

# Catalyst: components read the BigCommerce Storefront API directly
product = bigcommerce.storefront.query(productId)

# Backend-agnostic: components read a normalized schema,
# the backend is resolved in the data layer
product = orchestr.resolve("Product", productId)   # BigCommerce today, another backend later

The component that renders a product detail page does not change when the backend does. Only the resolver behind the schema does.

Migration paths: Stencil to Catalyst, or Stencil to a managed frontend

Teams on older Stencil themes face this fork directly. Migrating Stencil to Catalyst keeps you inside BigCommerce and moves you to a modern React framework that you then maintain. Migrating Stencil to a managed backend-agnostic frontend also modernizes the storefront, but hands the upkeep of the frontend foundation to a platform and keeps the backend swappable. Both are valid. The right one depends on how certain you are about staying on BigCommerce.

Decision checklist

Run through this before you commit either way:

• [ ] Is BigCommerce a settled decision for the next three to five years, or under review?
• [ ] Do you run, or expect to run, more than one commerce backend across brands or markets?
• [ ] Do you have a React team ready to own Catalyst and Next.js upgrades long-term?
• [ ] Does marketing need visual editing, and does it matter whether that editor is tied to one backend?
• [ ] If you migrate off Stencil, do you want the frontend rebuild to be reusable if the backend changes later?
• [ ] Is framework and security upkeep something your team wants to own, or hand to a platform?

Takeaway

Catalyst and Makeswift are good tools, and for a BigCommerce-committed team they are a clear upgrade over Stencil. The one thing they do not give you is backend flexibility, because they were never meant to. If your backend is settled, that is not a problem. If it is not, a backend-agnostic frontend keeps the storefront you build over BigCommerce today usable over a different backend tomorrow. The usual first step is a short technical call to map which BigCommerce data points your storefront actually needs, and whether the agnostic layer is worth it for your setup.