BigCommerce Developers

In-House
BigCommerce Developers

Stencil and Catalyst storefronts, Page Builder widgets,
marketplace apps and API integrations —
on the platform since 2010.

Schedule Your Call

We have been writing BigCommerce code since 2010, which makes us one of the longest-running development teams on the platform. We have also run our own stores on it, which teaches you things the documentation doesn’t: where the API is genuinely good, where the admin quietly fights you, and which limits are real versus which are configuration nobody got around to.

We build on Shopify and on headless too. That matters when you ask whether a piece of work is worth doing on BigCommerce at all — the answer isn’t shaped by it being the only thing we sell.

When you actually need a developer

Worth saying plainly, because it costs us work: a lot of what gets scoped as BigCommerce development isn’t development.

Theme settings, Page Builder, product data, customer groups and most merchandising are meant to be handled without code. If your list of problems is mostly “we can’t change X ourselves,” the fix is usually configuration and a walkthrough, not an engagement.

You need a developer when the storefront has to behave differently:

The template has to do something the theme doesn’t

Custom product page logic, conditional display rules driven by customer group, fitment or configurator behavior, category templates that need to work differently from the rest of the catalog. This is Stencil and Handlebars work, and it’s most of what a BigCommerce developer does day to day.

Marketing is blocked behind a developer ticket

The most common quiet frustration on established stores, and among the cheapest to fix properly. Custom Page Builder widgets turn a layout change from a ticket into something the marketing team does themselves, inside the design system rather than around it. We publish our own widget product on the marketplace, so this is well-worn ground.

The integration doesn’t exist

The thing you need talks to your ERP, your 3PL, a pricing service, or an internal system nobody outside the building has heard of. No marketplace app covers it. We build apps rather than only installing them — private apps for a single store, public apps when it’s worth publishing, and plain API integrations when neither is warranted.

Performance survived the obvious fixes

Images are optimized, the app list has been cleaned, and it’s still slow. At that point it is a code problem — render-blocking scripts, template-level query patterns, third-party tags loading in the critical path — and it needs measurement before it needs a rebuild.

The storefront needs to be an application

Real-time availability, complex account portals, configurators, catalogs that behave more like software than like pages. This is where Catalyst and headless earn their cost, and where a Stencil theme starts fighting you.

What we write

Stencil themes — Handlebars, SCSS and JavaScript, built so merchandising stays in your hands after launch rather than ours.

Catalyst and headless storefronts — React and Next.js against the GraphQL Storefront API, when the storefront genuinely needs to be an application.

Page Builder widgets — custom widgets so non-developers can build pages without breaking the design system.

Apps — private apps for your store, public apps on the marketplace, built against the REST and GraphQL APIs.

API integrations — ERP, PIM, 3PL, pricing, tax, whatever you already run. Including the unglamorous parts: retries, idempotency, and what happens when the other system is down at 2am.

B2B configurations — customer groups, price lists, quantity breaks, purchase orders and restricted catalogs, which are native on BigCommerce and better than they get credit for.

Migrations — Shopify to BigCommerce, Magento to BigCommerce, WooCommerce to BigCommerce, and off BigCommerce when that’s genuinely the right call. The redirect map gets built from live crawl data rather than the old sitemap, and verified before launch.

Apps we’ve published

The clearest evidence of what a development team can do is what it has shipped to other people’s stores:

How we staff the work

Senior people, start to finish. The developer who scopes your project is the developer who builds it. Nothing gets handed down after the proposal is signed, and nothing gets subcontracted.

You own everything. Repositories in your GitHub organization, infrastructure in your accounts, documentation written for a developer who has never seen the project.

We’ll tell you when the answer is smaller. We talk clients out of rebuilds regularly — usually because the store converts fine and the real problem is demand, or because a week of template work gets there instead of a quarter.

If you’re evaluating developers

Three questions worth asking anyone, including us.

Who writes the code? Ask specifically whether the person on the call is the person building it. The gap between the sales team and the delivery team is where most agency disappointment comes from.

What have you published? Building apps for the marketplace is a harder test than building for one client — review, versioning, and other people’s stores depending on your code.

What would you tell me not to do? A developer who agrees with every item on your list is reading the list back to you. The useful ones push back before the invoice, not after.

Start with the actual problem

Tell us what’s going on. If it turns out to be configuration rather than code, we’ll say so — and if BigCommerce isn’t the right home for what you’re building, we’ll say that too.

Schedule Your Call

Frequently Asked Questions

Do we actually need a BigCommerce developer?
Often not, and we will tell you when that's the case. Theme settings, Page Builder, product data and most merchandising are designed to be handled without code, and a lot of what gets scoped as development is really configuration nobody has had time to sit down with. You need a developer when you're changing how the storefront behaves rather than how it looks — custom templates, API work, an integration that doesn't exist, or performance problems that survived the obvious fixes.
What languages does BigCommerce development actually involve?
Stencil themes are Handlebars templates with SCSS and JavaScript, using BigCommerce's Stencil CLI for local development. Catalyst, the newer storefront framework, is React and Next.js against the GraphQL Storefront API. App and integration work is whatever you like against the REST and GraphQL APIs — we mostly write Node and TypeScript. The platform is not opinionated about it.
Stencil or Catalyst for a new build?
Stencil is mature, well understood, and right for the large majority of stores. It is not the limitation people assume — a well-built Stencil theme handles serious catalogs and serious traffic. Catalyst earns its cost when the storefront needs to behave like an application, or when you want full control of the render path. It is also a bigger maintenance commitment. We build both and will tell you which side of the line you're on rather than defaulting to the newer one.
Will the same people who scope the work build it?
Yes. We don't hand projects to a junior after the proposal is signed, and we don't subcontract the build. The developer you talk to on the call is the developer who writes the code.
Can you work on a store another agency built?
That's a large share of what we do. It starts with reading what's actually there — theme state, custom templates, which apps are load-bearing, what's been patched and why — so you know what you have before anyone proposes changing it. Inherited codebases are often better than their owners fear. Occasionally they're worse. Either way it's worth establishing before you commit budget against a guess.
Who owns the code?
You do. Repositories live in your GitHub organization, infrastructure in your accounts, and documentation is written for a developer who has never seen the project. No proprietary wrapper, no exit fee, no dependency on us continuing.