Quorum

Web design · BigCommerce

BigCommerce forcatalogs with rules.

Price lists, catalog structure, and a theme path chosen before anyone says headless. Checkout stays hosted.

The short answer

When the catalog has rules.

BigCommerce is the right build when the catalog itself is complicated: price lists, customer groups, product modifiers, or more than one storefront, and you still want checkout off a stack of plugins. It is a weak fit for a small retail catalog a simpler hosted store would run, or a content site with a few products. We choose Stencil unless the theme cannot do the job. Checkout stays on BigCommerce either way.

Catalog rules

Price lists and storefronts, or do not bother.

Choose BigCommerce when wholesale and retail need different prices for the same SKU, when buyer roles matter, or when two storefronts should share a catalog without sharing a theme hack. The admin has to be something your merchandiser will learn. We scope the catalog rules first, because they decide the templates.

Skip it when you have a few hundred simple SKUs, no B2B pricing, and the team wants the most common app ecosystem. Shopify is usually the smaller project. Skip it when long buying guides in WordPress are the asset. WooCommerce may fit. BigCommerce is not a visual upgrade for a store that is already fine.

  • Price lists or customer groups are a real requirement, not a someday idea.
  • Multi-storefront only if you truly operate more than one.
  • Checkout stays on BigCommerce.

Theme path

Stencil or headless, decided in writing.

Stencil is the default. It keeps the theme next to the catalog and the checkout the platform already runs. We design category, product, and landing templates against the real modifiers and options, not against a flat product that does not exist in your export. Page content that is not a product gets a home that does not fight the category tree.

A separate front end, including a Next.js storefront, is a second system: preview, deploy, and a checkout handoff. We propose it only when Stencil cannot express the merchandising, and the proposal says what is missing. ERP or inventory sync is scoped as an integration with an owner, not assumed because the platform has an API.

  • Catalog rules written down before template design.
  • Category and product templates tested with real modifiers.
  • Headless only with a stated gap Stencil cannot close.

Scope traps

Headless first, and a checkout rebuilt by habit.

The expensive miss is a headless project for a catalog Stencil would have served. You inherit a deploy, a preview problem, and a longer path to change a banner. The store does not get more capable. It gets more dependent. We will argue for the smaller path when the smaller path works.

The other miss is treating BigCommerce like a pile of checkout plugins from a different platform. Custom checkout that drops wallets, or a spreadsheet of 'special prices' applied by hand, recreates the problem you moved to escape. Price lists belong in the platform. If a rule cannot live there, it needs an explicit exception, not a quiet manual step.

  • No headless rebuild without a gap in the theme.
  • No manual price spreadsheets for prices the platform can store.
  • No custom checkout that drops the payment methods you already accept.

Catalog rehearsal

A buyer sees the price that buyer should see.

The test is a customer group. We log in as a wholesale buyer and as a retail shopper and confirm the price, the available products, and the checkout path. If both people see the same grid, the price list work is not finished. This is a rehearsal with your data, on staging, before launch.

We also confirm that a merchandiser can add a modifier, place a product in a category, and preview it without a developer. Redirects from the old catalog are checked while the old store still answers. A theme review that never logs in as a B2B buyer missed the reason you picked the platform.

  • Retail and wholesale previews show the correct price.
  • A merchandiser adds a product and a modifier unaided.
  • Checkout completes on the platform for each group you sell to.

Example engagement

A specialty retailer with wholesale and retail.

Specialty retailer selling to the public and to trade accounts. The public site showed one price. Trade prices lived in a spreadsheet the sales team emailed. The rebuild brief said 'headless' because a previous vendor liked the word. The catalog was not large. The pricing rules were.

We stayed on a Stencil theme and put trade prices in price lists tied to customer groups. The wholesale buyer saw different prices at preview. Checkout stayed on BigCommerce. Headless was written down as a later option only if a storefront Stencil could not serve showed up. It had not. The spreadsheet left the checkout path.

Price lists

Trade prices moved into customer groups on the platform

Stencil

Theme path chosen before any separate front end

The example uses anonymized results from a Quorum engagement. It is one account, not a benchmark you should budget against.

Questions

BigCommerce questions.

Is BigCommerce only for large catalogs?

No. It is for catalogs with rules. A smaller catalog with real price lists can be a better fit than a huge catalog of simple products that another platform already runs well. Size alone is a weak reason to move.

Do you replatform from Shopify or WooCommerce?

Yes, when the rules are why you are moving. The old store stays up until the catalog check and the redirects are done. Customers, orders, and URLs get a written map. We do not flip DNS because the theme looks finished.

Can marketing pages live here?

Campaign pages and guides can, if someone will edit them and they do not fight the category tree for the same intent. A large editorial operation may still want its own CMS. We decide that in the page map, not after launch.

Will you build a custom checkout?

We avoid it. The hosted checkout is part of why this platform is in the running. Branding and the fields you truly need are in scope. Replacing checkout is how payment methods get lost, and we will say that directly if it is the ask.

What do you need from our ERP?

The system that owns inventory and price, the direction each field syncs, and a person who can explain exceptions. If that is unclear, the store build can still start, and the integration stays a separate scoped job. We do not invent a sync to make the diagram look complete.

More in this lane

Other Web Design platforms.

Talk through bigcommerce.

One conversation. A diagnostic. A plan you can kill if it is not the work.