A BigCommerce developer worth hiring can show you three things inside a single call: a working reference build you can click through yourself, a Stencil theme repository you can actually see, and an integration they can describe at the field level, meaning which ERP field maps to which BigCommerce attribute. If a vendor cannot produce all three on the spot, they do not have them, and no amount of portfolio polish changes that.
We are MageMontreal, a BigCommerce development partner based in Montreal that also builds on Adobe Commerce, Magento Open Source and Shopify Plus. We are one of the vendors you might be evaluating right now, and we think that fact matters enough to say plainly in the second paragraph of a post about how to evaluate vendors. If you have not yet settled on BigCommerce as the platform, our comparison of B2B ecommerce platforms is a reasonable place to start before you read the rest of this.
In our experience, most hiring decisions in this category get made on portfolio screenshots. That is a problem, because screenshots tell you very little about a vendor. A screenshot proves a BigCommerce developer can theme a storefront. It proves nothing about whether that person can keep a catalog in sync with an ERP, model customer specific pricing correctly, or hand a finished build to your internal team without holding it hostage. Below are the 9 things that separate real capability from a well designed sales deck.
A BigCommerce developer working on a B2B catalog splits time across three distinct jobs, and most agencies are only genuinely strong at one of them. The first is catalog and data work: structuring products, variants, Customer Groups, and Price Lists so pricing behaves correctly for every buyer segment. The second is storefront work inside Stencil, BigCommerce’s Handlebars based theme engine, or increasingly inside Catalyst, BigCommerce’s newer headless framework.
The third job, and the one least visible in a portfolio, is integration work. This means connecting BigCommerce to an ERP such as Epicor Prophet 21, NetSuite OneWorld, or Microsoft Dynamics 365 Business Central, and keeping inventory, pricing, and order data synchronized in both directions. A BigCommerce developer who is strong at theming and weak at integration will produce a beautiful storefront that quietly desynchronizes from your ERP within weeks. That is the failure mode this whole post is built to help you catch before you sign.
This is the list to send a BigCommerce developer before the call, not after. Each item is one line of ask and one line of what a passing answer actually contains. Paste it into an email to every vendor on your shortlist and compare the answers side by side.
You do not need to write code to learn something real from a Git repository. Ask for read access and look at three things. First, the commit history: a healthy Stencil build shows commits spread across weeks, with messages that describe specific changes, not one enormous commit labeled “final.”
Second, look at where custom logic lives. If every piece of custom functionality is jammed directly into the Stencil theme rather than separated into a Script Manager snippet or a standalone app, that is a maintainability problem waiting to surface the first time you switch developers. Third, watch for the specific signal of a single person working under deadline pressure: no comments, no README, variable names like temp2 and fixThis, and a commit history that jumps from nothing to hundreds of files in one push. That pattern almost always means the build will be expensive to hand off to the next BigCommerce developer.
On BigCommerce, ask these five questions and listen for specificity, not confidence.
A BigCommerce developer who has done this work answers each of these in under a minute, with a specific example attached. A generalist reaches for platform agnostic language: “we handle integrations all the time” without naming a single system.
Budget overrun in this category is almost always a scope definition failure, not a rate problem. Well scoped BigCommerce development services define exactly which Customer Groups, Price Lists, and integrations are included before a contract is signed, so the categories below stop being a debate mid project.
| Belongs in Fixed Scope | Becomes a Change Order |
| Theme setup using Stencil defaults or Cornerstone as a base | A second storefront added mid build under Multi-Storefront |
| One Customer Group and Price List structure defined upfront | Additional Customer Groups requested after go live |
| One ERP integration scoped and field mapped in the statement of work | A second ERP or CRM added after kickoff |
| Standard Catalog API v3 import for the agreed SKU count | Ongoing catalog cleanup caused by bad source data |
| Webhook configuration for the systems named in the statement of work | New webhooks for tools added after launch |
| Documentation and handover for the agreed scope | Training sessions beyond the agreed handover window |
Read our full breakdown of BigCommerce development services if you want the longer version of this scoping conversation before you sign anything.
A BigCommerce agency’s integration work almost never appears in its portfolio, because it is invisible by design when it works. Nobody screenshots a webhook. Ask instead for a specific example: how did they connect BigCommerce to a tax engine like Avalara, and what happened the last time a rate table changed mid quarter.
The key diagnostic question is about failure recovery. Ask any BigCommerce agency what happens when a webhook silently fails, how they find out, and how long it takes them to notice. An agency with real integration depth will describe monitoring and alerting. One without it will describe a customer complaint as the detection method. For the deeper technical picture of how ERP connections actually get built on this platform, our post on Epicor P21 and BigCommerce Integration covers the middleware, native app, and custom build options in more detail than fits here.
A BigCommerce B2B developer needs working fluency in a specific set of native features, not just theming skill. Customer Groups segment your buyers, and Price Lists apply variant level pricing overrides to those groups, which is how a wholesale buyer sees different unit pricing than a retail visitor on the same catalog. Getting this wrong means either every buyer sees the same price, which defeats the purpose of B2B pricing, or pricing breaks silently for one segment during a promotion.
Beyond pricing, a capable BigCommerce B2B developer should be comfortable with BigCommerce B2B Edition features including Company Accounts, multi user buyer roles, and approval workflows, along with Multi-Storefront setups for businesses running separate B2B and B2C experiences from one back end. If your procurement buyers require cXML punchout so their purchasing system can shop your catalog directly, that is a specialized, less common skill, and it is worth confirming upfront rather than discovering the gap mid build.
Cost depends on catalog size, the number of Customer Groups and Price Lists required, and whether an ERP integration is in scope. A build with one ERP connection and standard B2B pricing costs meaningfully less than one requiring Multi-Storefront, cXML punchout, and multiple integrations.
Timelines scale with integration complexity rather than theme complexity. A storefront with one ERP connection and a defined Customer Group structure typically moves faster than one requiring custom Catalyst development or multiple third party system connections.
The most common risk is a webhook or sync process that fails silently, leaving inventory or pricing out of date without anyone noticing until a customer complains. Ask specifically how a vendor monitors integration health, not just how they build it.
That depends on your existing systems, your team’s technical resources, and how much customization you need beyond native B2B features. Our comparison of B2B ecommerce platforms (link) covers the tradeoffs in more depth.
Businesses with catalogs under roughly 500 SKUs, no ERP, no customer specific pricing, and no punchout requirement are usually better served by a stock theme and a clean product import than by an agency engagement.
