How much does a BigCommerce Catalyst build cost in 2026?

In our experience, a BigCommerce Catalyst implementation typically ranges from £60,000 to £120,000. This covers the Next.js development, custom API middleware, and CI/CD pipeline setup. It is significantly more expensive than a standard Stencil theme build (typically £15,000–£40,000) but provides the performance benefits of React Server Components.

When does BigCommerce Catalyst make sense vs Stencil?

Catalyst makes sense when you have a dedicated internal React engineering team and require aggressive performance tuning (like an LCP under 1.5s) or complex B2B logic that Stencil's Handlebars engine cannot support. If your GMV is under £5M and you just want a stable storefront, stick with Stencil.

Is BigCommerce deprecating Stencil?

No. While BigCommerce has deprecated older frameworks like Blueprint, Stencil remains a fully supported native theme engine in 2026. Catalyst is positioned as an alternative for headless architecture, not a mandatory replacement for Stencil.

BigCommerce Web Development: Stencil vs Catalyst Costs (2026)

The decision between BigCommerce Stencil, Catalyst, and a fully custom headless architecture comes down to your in-house engineering capacity and multi-storefront complexity. For most merchants under £10M GMV, Stencil themes remain the most cost-effective path. However, if your frontend requires aggressive performance tuning or complex B2B routing, Catalyst’s Next.js foundation justifies the engineering overhead. Here is our decision framework for 2026.

Why the BigCommerce frontend decision matters more in 2026

The BigCommerce ecosystem has bifurcated. On one side, you have Stencil—the platform’s native Handlebars-based theme engine. On the other, you have Catalyst, the composable storefront framework built on the Next.js App Router and React Server Components (RSC). Historically, moving away from Stencil meant building a custom headless frontend from scratch, usually resulting in a £100,000+ agency engagement. The introduction of Catalyst has compressed that timeline, providing a pre-wired reference architecture that consumes the BigCommerce GraphQL Storefront API out of the box. But a lower barrier to entry does not mean zero ongoing maintenance.

We regularly speak to merchants who assume Catalyst is just a "faster theme". It is not. It is a separate Node.js application that requires a distinct hosting layer, a CI/CD pipeline, and a team that understands React state management. If you evaluate these paths based purely on Lighthouse scores, you will miscalculate the total cost of ownership. You are trading platform constraints for infrastructural responsibility.

When Stencil themes still win for mid-market builds

Despite the industry noise around composable commerce, Stencil is not legacy software. If your primary requirement is a stable, low-maintenance storefront that your marketing team can operate without filing Jira tickets, Stencil is usually the correct choice. The native engine handles session management, cart state, and checkout routing without requiring middleware. For stores in the £1M–£10M GMV band, the business value of a headless rebuild rarely exceeds the opportunity cost of the engineering hours required to maintain it.

If your LCP (Largest Contentful Paint) is currently above 3.5 seconds, you can typically bring it under 2.0s on mid-tier mobile simply by auditing your Stencil theme, lazy-loading off-screen images, and removing redundant third-party scripts. We once measured a Stencil homepage that loaded 11 separate analytics scripts. Eight of them tracked the exact same event. Two of them no longer had active dashboards. Fixing that does not require a Next.js migration; it requires a developer with a mandate to delete things.

Stencil only fails when you need complex, dynamic UI patterns—like nested customer-specific pricing calculators or highly interactive product configurators—that fight against the Handlebars rendering lifecycle.

The Catalyst framework: Next.js performance vs engineering overhead

If you have outgrown Stencil's templating constraints, Catalyst is the next logical step. By leveraging the Next.js App Router, Catalyst uses React Server Components to stream rendered HTML from the server, significantly reducing the JavaScript payload sent to the browser. This architecture is genuinely fast. However, it shifts the complexity from the frontend browser to your server-side data fetching strategy. BigCommerce’s API limits are generous, but a poorly optimised Next.js application can still hit rate limits if you are not caching responses effectively.

We have seen this shape repeatedly: a merchant migrates to Catalyst to solve performance issues, but the development team treats the Next.js layer like a traditional Single Page Application (SPA). They fetch product data client-side on every route change, resulting in a waterfall of network requests that negate the framework's benefits. To succeed with Catalyst, your team must be proficient in incremental static regeneration (ISR) and server-side caching.

If your engineers are more comfortable with Remix, you might find yourself comparing Catalyst against Shopify Hydrogen. Hydrogen uses the Remix framework and the Shopify GraphQL Storefront API to achieve similar headless outcomes on the Shopify side, offering a different set of trade-offs for React teams.

Full headless architecture: Multi-region and complex B2B routing

There is a tier of enterprise merchants for whom even Catalyst’s opinionated structure is too restrictive. If you are running complex B2B operations across multiple regions, integrating a heavy ERP like NetSuite, and relying on a standalone CMS like Contentful or Sanity, a fully custom headless build becomes necessary.

In these scenarios, BigCommerce effectively becomes a microservice—a commerce engine responsible solely for cart calculation, promotional logic, and checkout. The frontend is entirely decoupled. This is where BigCommerce’s native Multi-Storefront (MSF) capability shines compared to other platforms. You can run four distinct regional frontends, each with different pricing logic and content, all feeding into a single BigCommerce backend instance.

However, this flexibility comes at a steep price. You are now responsible for the entire orchestration layer. If a webhook drops or an API token expires, your checkout breaks. We only recommend this path for merchants with an annual GMV north of £20M and an internal engineering team capable of managing an enterprise-grade CI/CD pipeline. For everyone else, the operational complexity simply multiplies the surface area for things to break.

Real costs: Stack mapping for £5M–£20M GMV merchants

Platform pricing is rarely transparent. While standard BigCommerce tiers are public, enterprise costs are negotiated. In our experience, a BigCommerce Enterprise subscription typically runs around £1,000–around £2,500/month, depending on your GMV and order volume. Adding the B2B Edition usually adds roughly £500/month to that base. But the platform fee is only the foundation. Your frontend choice dictates your engineering budget.

BigCommerce Frontend Cost Matrix (2026)

Stencil Theme Build: Typically £15,000–£40,000. Best for standard B2C or simple B2B. Ongoing maintenance is minimal, mostly focused on app integrations and conversion rate optimisation.
Catalyst (Next.js) Implementation: Typically £60,000–£120,000. Best for performance-led brands with existing React capability. Requires ongoing budget for Vercel hosting and routine dependency updates.
Custom Headless / Composable: Typically £150,000–£300,000+. Best for complex multi-region enterprise architectures. Requires a dedicated internal engineering team to manage the middleware and orchestration layer.

If you are evaluating whether to switch platforms entirely, read our BigCommerce vs Shopify decision guide to understand how these costs compare to a Shopify Plus migration.

How to audit your current BigCommerce frontend in 5 steps

Before committing to a headless rebuild, you must definitively prove that your current architecture is the bottleneck. Do not migrate on a hunch. Follow this procedural audit to isolate your performance issues.

Export your Core Web Vitals report from Google Search Console. Filter for mobile URLs failing the LCP (Largest Contentful Paint) or INP (Interaction to Next Paint) metrics. You should see a clear pattern of failing templates, usually the Product Detail Page (PDP).
Run a WebPageTest audit on a failing PDP. Set the connection to 4G and the device to a mid-tier Android phone. You need to identify whether the delay is Time to First Byte (TTFB) or client-side rendering.
Analyse the Stencil Bundle size. Use the Stencil CLI to bundle your theme locally. If your uncompressed JavaScript exceeds 1.5MB, your issue is likely bloated third-party apps, not the Stencil framework itself.
Audit your third-party script execution. Open Chrome DevTools, navigate to the Network tab, and filter by JS. Identify which external domains are blocking the main thread during initial load. Defer or remove non-critical tracking scripts.
Measure the impact of native image optimisation. Ensure your Stencil theme is using the built-in Akamai CDN for image delivery and that responsive image srcset attributes are correctly configured for product galleries.

What to actually do next

Deciding on your BigCommerce frontend architecture is a permanent commitment to an operational model. If your annual GMV is under £5M and your only reason to go headless is "we want a faster site," do not approve the Catalyst build. Hire an agency to deeply audit and refactor your Stencil theme. You will achieve 80% of the performance gains for 20% of the cost.

If you are pushing £15M GMV, have a complex multi-storefront requirement, and already employ React engineers, Catalyst is the correct strategic choice. It provides the architectural freedom of headless commerce without the punishing boilerplate of a scratch build. Your next step should be a technical discovery phase.

Do not start with design. Map your current third-party app stack, identify which ones have native GraphQL API support, and document your specific B2B routing rules. If you need an objective assessment of whether your specific catalogue complexity justifies a Next.js rebuild, bring us your data model and we will map the architecture. The goal is to build the lightest possible frontend that still supports your commercial requirements.