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 — Brief for the VP of Product (P&E)
A subscription platform built native to BigCommerce — verified end-to-end, live on real sandbox charges today, and ready to put in front of a few customers before the window closes.
The bottom line. This is not slideware. The product is verified end-to-end with zero known failures, and a live proof of concept executes real Stripe sandbox charges right now. Subscriptions are the capability gating the Mustang conversation (BigCommerce's >$5M-GMV WooCommerce migration push) with >$5M-GMV merchants, and BigCommerce has no native answer. The ask is narrow: P&E (Platform & Engineering) support to take this POC to a few customers between now and mid-August.
It's real, and it works. Two independent proofs, both verifiable today:
- Verified end-to-end, zero known failures. Not a self-reported status — every claim is checked by an automated, repeatable test, derived from code at build time. See the live count →
- A live POC, not a demo deck. The merchant admin runs on real Stripe sandbox PaymentIntents — including a genuine
card_declinedexception, so the unhappy path is proven, not assumed. A public storefront offers subscribe-and-save natively on a real BC product page. No install, no signup required to view.
The charge engine is gateway-agnostic by design — it rides BC's stored-instruments vault. Stripe is the configured gateway in today's sandbox POC; BC Payments is the GA (General Availability) rail.
The last two weeks. 30+ capabilities advanced across roughly 19 of the 28 product epics — the portal's momentum feed carries the live, git-derived count. That is the answer to "what's been pushed forward recently": steady, broad movement, not a single feature.
Why the market is pulling. BigCommerce has no subscription product that is BC-first, mid-market-ready, and unified with BC Payments. BC Payments' March 2026 launch made that gap larger, not smaller — every existing subscription app now forces merchants to run a parallel payment relationship outside their BC Payments account. For Mustang this is the gate: above ~$5M GMV, target merchants lean heavily on subscriptions and today run free Woo Subscriptions. The commercial answer is not "cheaper than free" — it's the migration unlock. BC-native subscriptions remove the anchor keeping these merchants on Woo: one payment relationship instead of two, mid-market depth Recharge and Woo lack, native to the BC order and catalog model. Subscriptions stop being the reason a Mustang-target merchant won't migrate.
What's true today vs. what's next.
| Proven today | Next — and the risk it carries |
|---|---|
| Verified end-to-end, zero known failures | Drive the remainder to the same bar |
| Real recurring charges (Stripe sandbox) | BC Payments GA rail is partner-track (BigCommerce's third-party certification process) — a real dependency to size |
| Native storefront + admin, live | Customer validation with a few real merchants |
| Ships today as a marketplace app, designed so a deeper native build stays an option | ~30% bounded, known app-side rewrite cost if that path is ever taken |
| — | Pricing and packaging are not yet research-backed |
The ask. P&E support, now through mid-August, to take this POC to a few customers and validate it as a product line. The lead's Mustang capacity is business-as-usual through July and ramps down around mid-August; that is the window to convert a working proof into a customer-validated one. The specific resourcing is the sponsor's call. What P&E support buys is a customer-validatable POC inside that window — the strongest possible basis for the product-line decision.