BigCommerce theme customization and design for B2B stores.

ProjectThunder customizes BigCommerce themes for B2B companies. We are a California B2B ecommerce studio, founded in 2004 and a BigCommerce Partner, that builds Stencil and Catalyst storefronts, sets up B2B Edition and integrates BigCommerce with SAP, Microsoft Dynamics and Sage. Theme work runs from Cornerstone edits and custom Stencil themes to full redesigns, with the ERP's pricing and stock shown on the page.

We have launched 150 B2B storefronts across ERPs. Our median client relationship is 10 years, and everyone works California hours, developers included. Once we look after a store, small ongoing theme changes run on retainer hours, so a new banner layout or a category template tweak does not need a project of its own.

Stencil is BigCommerce's theme framework: Handlebars templates, SCSS styles and JavaScript, with theme settings your team can change in Page Builder, the visual editor. We work on themes locally with Stencil CLI and keep them in version control, so every change has a history and a way back.

Cornerstone is BigCommerce's default Stencil theme. BigCommerce maintains it and publishes its updates, and it is the usual starting point for custom themes. Marketplace themes are the third option, maintained by their own developers.

• Customize Cornerstone when its layout mostly fits and the changes are styling, a few templates and some widgets. It costs the least to start, and its updates can still be merged in.
• Customize a marketplace theme when one already looks close to what you want. Updates then come from that theme's developer, on their schedule, so check how actively it is maintained before you commit.
• Build a custom theme, usually still from Cornerstone's code, when the design, navigation or B2B ordering pages differ so much that you would be working against the base theme on every page.

Our usual starting point for a B2B theme is Cornerstone's code, with our changes kept in their own files where we can. BigCommerce's own theme guidance points the same way: put new styles in a separate file instead of editing the original stylesheet, which leaves less to untangle at update time.

This is one of the most common complaints about customized BigCommerce themes. A new theme version is not applied to a copy you have edited, so every customization has to be carried onto the new version by someone. Left alone, the store stays on an old version and the gap grows with each release.

How we carry customizations through an update:

1. Back up first. The live theme and its config.json, which holds most of the theme's settings.
2. Keep the base and your changes in version control. The base theme on one branch and your store's theme on its own, so an update is a reviewed merge instead of files copied by hand.
3. Read what changed. Cornerstone's changelog, or the release notes from your theme's developer.
4. Merge, then preview. Run the merged theme locally with Stencil CLI or as an unapplied copy, and test the home, category, product, cart, account and quick order pages, plus every app that draws on the storefront.
5. Apply, with the old version ready. If something slips past testing, the previous version can go straight back on.

Page Builder widget content is stored outside the theme files, so it stays through an update as long as the new version keeps the regions those widgets sit in. We check every region before we apply.

One request to your team while an update is in progress: hold off on editing theme files in the control panel. Those edits are not in version control, and the merged theme will overwrite them.

Most broken BigCommerce customizations come down to a handful of causes. They are worth checking before anyone rewrites anything.

• Version drift. The edited copy stopped taking updates years ago. Fixes and features in newer versions never reached it, and each skipped version makes the eventual merge larger.
• App scripts. Apps add scripts to the storefront and often look for specific markup in the theme. Change a template, and a review widget, search box or upsell block can vanish or show twice. Two apps can also conflict with each other.
• Page Builder and template edits pulling against each other. A Page Builder setting only works if the theme's stylesheets still read it, so a color hard-coded in the files makes the setting do nothing. A template edit that removes a region takes the widgets placed there off the page.
• The wrong copy. The edit went into a theme copy that is not the one applied to the storefront.
• Checkout expectations. Checkout is mostly separate from the theme. Styling carries over, and deeper checkout changes are their own piece of work.

Our fix starts with a diff: the theme against the version it started from, with every change listed. Then we decide what to keep, what moves into its own files and what to retire.

A B2B redesign has more to plan than a new look. Buyers log in to see their price, what is in stock and what they owe, and those numbers come from the ERP. The design has to make room for them from the first sketch.

• Their price, on every page they see it. Customer-specific pricing on category and product pages, a clear state while a price loads, and no add-to-cart when the ERP holds no price for that buyer.
• Stock they can trust. Available quantity, by warehouse where it matters, worded the way your sales team talks about it.
• Ordering for people who know their SKUs. Quick order, reorder from past orders and shopping lists.
• Account pages worth logging in for. Order history, invoices, open balance and credit, usually read from the ERP.
• URLs kept. Product and category URLs are store settings, separate from the theme, so a redesign leaves them in place. Anything that has to move gets a 301 redirect.

We integrate the ERP with the store, and your ERP partner implements or moves the ERP itself. Our BigCommerce ERP integration guides cover SAP, Microsoft Dynamics and Sage, and B2B Edition setup covers company accounts, price lists and quotes.

Theme customization is Stencil work. Stencil is BigCommerce's hosted theme framework, Page Builder works with it, and BigCommerce runs it. Catalyst is BigCommerce's Next.js storefront for headless builds. A Stencil theme does not carry over to it, so moving is a front-end rebuild.

Stay on Stencil when the redesign fits the theme model and your team edits the store day to day. Look at Catalyst when the design needs control Stencil cannot give, or the storefront shares a front end with other apps, and you have a team to own a Next.js project. We build both, and we wrote up how we choose in BigCommerce Stencil vs Catalyst. More on our BigCommerce work is on the BigCommerce page.

Every project starts with 50 to 100 hours of planning at $100 an hour. Planning sets the design, the scope and the cost of the build before it starts, so the budget is known up front. The build then runs at $185 an hour, or $165 an hour prepaid on 7-day terms, and every change starts from an estimate you approve.

After launch, a 20 to 50 hour monthly retainer covers the small ongoing changes a theme always needs: a new widget, a template tweak, a seasonal layout, a theme update merge. The same developers do the work.

What moves the cost: how far the design is from the base theme, how many templates change, how much B2B and ERP data appears on the page, how many apps draw on the storefront, and how far an existing theme has drifted from its base. Work is tested in four layers: automated unit tests, AI-assisted developer testing, human QA and your sign-off on agreed test cases. More detail is in how we charge.