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.
Mustang & Subscriptions — GTM Readiness Brief
For GTM/Sales: whether subscriptions can stop being the reason a subscription-heavy, >$5M-GMV merchant won't take the Mustang conversation (BigCommerce's >$5M-GMV WooCommerce migration push).
The bottom line. Yes — open the conversation now. There's a working proof of concept today, verified end-to-end with zero known failures: the engine works. The migration reason is BC-native consolidation, not a cheaper-than-free price war. One caveat to size and carry honestly: the unified-BC-Payments rail that is the differentiation is partner-track (BigCommerce's third-party certification process) for GA (General Availability).
The blocker — why there's no conversation today. Above ~$5M GMV, these merchants lean heavily on subscriptions, and they run WooCommerce Subscriptions because it's there and free. Without a credible BC answer, there's no Mustang conversation to open. The incumbents don't break that anchor:
| Option | What it is | Why it doesn't unblock Mustang |
|---|---|---|
| Woo Subscriptions | Free, WordPress-shaped | Keeps the merchant on WP; built around WP, not BC's order/catalog model |
| Recharge on BC | A Shopify-shaped port | No App Extensions integration (Script Manager injection only — source); price lists incompatible (source); no Multi-Storefront on BC Checkout Integration (source); requires Stripe, Braintree, or Authorize.net — BC Payments not a supported gateway (source) |
| Ordergroove | Enterprise | Priced and integrated for ENT; mid-market can't justify it |
Every subscription app verified in this competitive scan — Recharge, PayWhirl, Rebillia, MINIBC — forces a payment relationship outside BC Payments: a second processor, second payout, second dashboard.
The migration reason — BC-native, not bolted on. Three things a ported app structurally can't match:
- Unified BC Payments — one payment relationship, one payout, one dashboard, instead of a separate Stripe, Braintree, or Authorize.net processor account.
- Mid-market depth — Price Lists drive subscription-only pricing; Customer Groups segment subscribers; Multi-Storefront/channel-aware from day one; B2B Edition (approval workflows, purchase orders) by Phase 2.
- Native order & catalog — subscriptions enabled on existing BC products, no catalog duplication; renewals create native BC orders.
Beachhead: merchants who outgrew Recharge's fit but can't justify Ordergroove's price.
"Commercially viable vs free Woo" — answered right. Not a price war. Pricing and packaging aren't set, and this won't win on "cheaper than free." Viability is the migration unlock: subscriptions stop being the reason a Mustang-target merchant stays on WP. The pitch is consolidation — fewer payment relationships, mid-market depth Woo and Recharge lack, native to BC's order and catalog model.
What's true today vs. what's next.
- Today (proof, not slideware): the merchant admin runs on real Stripe sandbox payments — including a genuine card-declined exception, handled — so the failure/dunning path runs, not just the happy path. A public storefront (Kibble & Co., a live site on a real BC catalog) offers subscribe-and-save natively on the product page. The product is verified end-to-end, zero known failures — checked by automated tests against the real spec, not a slide claiming it works.
- Next (size and name it): the POC charges through Stripe sandbox today; the unified-BC-Payments rail — the core differentiation — is canonical by design but partner-track for GA (a real dependency). Pricing/packaging is unvalidated. It ships as a marketplace app; native graduation is a future BC decision, not a commitment.
What to say to a merchant.
"You're on Woo for subscriptions because it's free and it's already there. On BC, subscriptions run through your BC Payments account — one payout, one dashboard, no second processor to reconcile. They live on your existing BC catalog and orders, not a bolted-on system. If you outgrew Recharge but can't justify Ordergroove, this is built for exactly that gap."
Lead with consolidation and fit. Never with price.
The ask. Open the Mustang subscriptions conversation now — the blocker is cleared enough to pitch credibly.
- Walk the live POC (admin + storefront, shared preview password) before the next Mustang merchant call, and carry it in as the subscriptions answer.
- Bring one sized caveat into that call: GA on the BC Payments rail is partner-track — name it as a dependency, not a gap.
- Secondary (P&E (Platform & Engineering) track): help line up a few target merchants to validate pricing. The closer to a customer-validatable POC, the stronger the P&E backing. Window: now → mid-August.