Your BigCommerce store is broken. We fix it fast.

Pricing is a fixed written quote for your scope. Send the details on WhatsApp and I reply within one working day. A batch of bugs or one deep root cause, like a failing Stencil build or an unstable Checkout SDK flow, is the Bug-Fix Sprint. Down-store emergencies and ongoing cover are quoted as a retainer, with a stabilization sprint available for deep rebuilds. You always get a fixed price before any work starts.

Yes. stencil bundle or stencil push failures (“Could not activate theme”, webpack/BrowserSync build errors, a broken config.json, or a missing dependency in package.json) are one of our most common BigCommerce fixes. We reproduce the build locally with Stencil CLI, read the actual build log, fix the offending template or config, and push a clean bundle. The theme deploys through Git so you can roll back any version.

Usually a {{> }} partial path that points at a template that doesn’t exist, a custom helper that isn’t registered, or a malformed {{#each}} / {{#if}} block. BigCommerce will blank the region or fail the build with something like “The partial header/account could not be found”. We trace the error to the exact template, restore the correct partial or helper, and add a check so the region renders again.

A 429 means your integration is exceeding BigCommerce’s API quota for your plan. The fix is rarely “ask for a higher limit”, it’s adding exponential backoff, respecting the X-Rate-Limit-Time-Reset-Ms header, batching writes, and moving heavy reads to the GraphQL Storefront API or webhooks instead of polling. We rebuild the integration so your ERP, PIM, or shipping sync stays inside the quota and stops dropping data.

Yes. A custom build on the BigCommerce Checkout SDK or a misconfigured Optimized One-Page Checkout can throw on load, skip the shipping or payment step, or fail to take payment. We debug the SDK flow end to end, the checkout service calls, the step rendering, and the payment provider integration, reproduce it on a sandbox, fix the failing call, and verify a real test order completes before going live.

BigCommerce deactivates a webhook after repeated non-2xx responses from your endpoint. So if order/created or product/updated stops reaching your system, the root cause is usually a slow or erroring endpoint, an SSL/timeout issue, or a payload your handler can’t parse. We check the webhook delivery history, fix the endpoint so it returns 200 fast, re-subscribe the events, and add retry handling so a single blip doesn’t kill the integration.

Yes. Variant pickers showing the wrong price, image, or stock usually trace to an option-set / SKU mapping problem, a stale theme cache, or a Handlebars template reading the wrong product field. We isolate whether it’s data (option sets / SKUs) or presentation (the theme template), fix the right layer, and confirm every variant resolves to the correct price and image.

Yes. A broken Script Manager entry, a GA4 tag, a marketing pixel, or a custom script, can throw an uncaught error that breaks other storefront JavaScript (including add-to-cart or the variant picker). We find which Script Manager tag is failing, fix or correctly gate it (right location, right page scope), and confirm the console is clean again.

Sandbox or local Stencil preview first, every time. We reproduce the bug on a stencil-cli preview or a sandbox store and fix it there before anything touches your live storefront. Because theme changes ship via stencil bundle + Git, the live push is a reviewable, revertible theme version, not a blind edit in the file browser. API and webhook changes are tested against a sandbox store too.

Yes, that’s the whole point of the staging-first, Git-backed workflow. We never edit the live theme directly. Every theme fix is a new stencil push version you can roll back with one click, and we verify the fix against your exact symptom before handing it back. If anything regresses inside 14 days, we re-fix it free.

For an emergency, a down storefront, a failing checkout, or a Stencil build that won’t deploy, we open a triage thread within 4 working hours and prioritise it ahead of standard tickets. A single well-defined bug is typically fixed in 24-48 hours. A larger sprint depends on scope, but you get a clear SLA window in our first reply, before any work begins.

Yes. Every fix carries a 14-day warranty: if the same bug returns within 14 days of sign-off, we re-fix it at no charge. We also hand back a short write-up of the root cause and what changed, so you’re never left guessing what was done to your store. For broader stability, the Emergency / Retainer tier keeps us on call.