How this was built
Built primarily with Claude Code (Anthropic's agentic coding tool), under direct human direction — the architecture, specification, and review decisions are the operator's; the AI generates code against that spec. The output is conventional TypeScript, Astro, and React — standard, maintainable code, not a proprietary format tied to the tool that helped write it. Quality claims here aren't self-assessed: every one is backed by an automated, regenerating verification ledger, not a status doc — see Verified Throughput. For a structured engineering review, see Code Review.
BC-Native Subscriptions — Sales Engineer Demo & Objection Brief
How to show it live, label fidelity honestly, and answer "is this real / production-ready / how does it integrate."
The bottom line
This is a working POC, not slideware: a public storefront you can click with no install, and a merchant admin running real Stripe-sandbox charges (live pi_*, including a genuine card_declined). Every feature is checked by an automated, repeatable test before it ships — not a status doc — and there are zero known failures right now. That's not a number to memorize for a prospect; it's a fact you can stand behind without hedging.
Demo path — lead with the no-install surface
Label every step with its fidelity tier out loud. Three tiers exist: live app (clickable), recorded walkthrough (where one exists), design mockup (the prototype gallery — UX only, never call it shipped).
- [live] Open the public Kibble & Co. storefront — no install, no login: storefront.bcsubs.app. Browse to a product page; show subscribe-and-save offered natively on the PDP (real BC catalog, BC's own checkout — no bypass).
- [live] Open the merchant admin (
admin.bcsubs.dev, shared preview password). Open a subscription's detail; show a renewal charge backed by a real Stripe sandbox PaymentIntent (pi_*), not a screenshot. - [live] Open Exceptions; show the genuine
card_declined— a real failed charge, observable and replayable. - Subscriber self-service (skip / swap / pause / cancel) lives behind shopper login on the storefront. Sign in on the storefront account if you have a seeded shopper, otherwise narrate it from the admin's subscription detail — don't promise a flow you can't show.
- [live] Hand to integration: open the OpenAPI docs at
api.bcsubs.dev/docs.
Before any live demo: smoke-test the admin pi_* and the declined exception yourself — the admin sits behind the preview gate, so confirm it renders before you're in front of the room. Do not demo gift purchase/claim live (the redeem route 404s today, per the route-orphan audit).
Integration story
OpenAPI contract + live docs (/docs, reachable). SDKs ship for React, Catalyst (BC's headless stack), and a framework-agnostic Web Component for Stencil / non-React storefronts, plus a component library and OKLCH design tokens. The documented headless drop-in:
<script src="https://bc-subscriptions-cdn.pages.dev/v1/bc-subscriptions-widget.iife.js"></script>
<bc-subscriptions-widget product-id="..."></bc-subscriptions-widget>
Caveat — the CDN bundle publishes on a
storefront-webcomponent-v*release tag and 404s until one is cut. Verify the URL serves before pasting it in a live demo; until then, demo the API (/docs) and the SDKs, and present the snippet as the documented integration path, not a live asset.
What's true today vs what's next
Today: thoroughly tested with zero known failures; a subset is live in the sandbox; the recurring-charge rail runs on Stripe sandbox now. Next: GA (General Availability) on the BC Payments rail (the unified-payments story) is partner-track (BigCommerce's third-party certification process) — the one real dependency to size, not a gap to hide. Ships as a BC marketplace app; native graduation is a future BC org decision, not a commitment.
Objection handling
| Objection | The answer |
|---|---|
| Is it production-ready? | Yes, with one named exception. Every feature is checked by an automated, repeatable test before it ships — not a status doc — and there are zero known failures right now. A subset is already live. The one real gap: GA on the BC Payments rail is partner-track, so this runs on Stripe sandbox until that's resolved. That's a dependency to size, not a corner being cut. |
| vs Recharge | First-class BC-native, not a port. Recharge's documented BigCommerce integration uses Script Manager injection only — no App Extensions on Orders, Products, or Customers pages (source); price lists explicitly incompatible (source); no Multi-Storefront on the BC Checkout Integration (source); separate Stripe, Braintree, or Authorize.net relationship required — BC Payments is not a supported gateway (source). |
| vs free Woo Subscriptions | Not a price fight — pricing isn't set yet, so don't quote one. It's the migration unlock: above ~$5M GMV these subscription-heavy merchants stay on Woo because it's free and there's no BC-native answer. This removes that anchor — unified with BC Payments, one payment relationship, mid-market depth Woo and Recharge lack. |
The ask / next step
Take this script into your next merchant and partner conversations. Lead with the public Kibble & Co. URL, label each step's fidelity tier, and answer "is it done?" with exactly what's tested and what's live — never claim more than that. Bring back the objections that land hardest; those become the next demo iteration.