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 — Technical Viability Brief
For the engineering leader evaluating whether this is sound, what the lift to GA (General Availability) is, and what risk it carries as a product line.
The bottom line
This is a BigCommerce-native subscription engine built on BC's own primitives — App Extensions, the native order system, Price Lists, Customer Groups, Multi-Storefront — with a gateway-agnostic recurring-charge rail. Most of it already exists and runs against an automated test suite, not a status doc someone updates by hand: broad coverage across the product's acceptance criteria, zero known failures. See the live, always-current count → The remaining lift to GA is dominated by one external dependency — BC's partner-track payment rail (BigCommerce's third-party certification process for a partner app to use BC Payments as its rail) — not greenfield engineering.
Architecture — native, not bolted on
Subscriptions are enabled on existing BC products (no catalog duplication). Renewal charges produce native BC orders; inventory, tax, shipping, and reconciliation ride BC's existing surfaces. App Extensions live on the Orders/Products/Customers pages; Price Lists drive subscription-only pricing; Customer Groups segment subscribers; the design is Multi-Storefront/channel-aware from day one.
The charge rail is the load-bearing decision: every recurring charge routes through BC's stored-instruments vault, regardless of which gateway the merchant runs. It's gateway-agnostic by design, and our app holds zero PCI scope — raw card data never touches our endpoints. Stripe is the configured gateway in the live sandbox POC, not a lock-in. The integration surface is an OpenAPI contract plus SDKs: React, Catalyst (BC's headless stack), and a framework-agnostic <bc-subscriptions-widget> Web Component for Stencil/non-React storefronts.
Quality posture — verified, not claimed
State is derived from code and tests, not asserted in a status doc. Every acceptance criterion either has a passing, automated, repeatable scenario behind it, or it doesn't — there's no self-grading in between. The discriminating fact: zero known failures. The acceptance criteria that aren't there yet aren't broken — they're in review, or they're the kind of thing only provable live in production or by a human sign-off (security review, accessibility audit), not by an automated test. Full breakdown, regenerated on every push →
Lift, and what's true today vs next
| Verified today (sandbox POC) | Roadmap | |
|---|---|---|
| Merchant admin | Real Stripe sandbox PaymentIntents (live pi_*, including a genuine card_declined) on BC store cdfqf9k6zf |
— |
| Storefront | Public Kibble & Co. storefront on real BC catalog, subscribe-and-save offered natively on the PDP | — |
| Coverage | Broad, automated, zero known failures — exact count | Close the remaining gap the same way: automated proof, not a status update |
| Payments | Gateway-agnostic rail proven on Stripe sandbox | BC Payments rail = partner-track (the GA dependency to size) |
| Scope | Core subscriber + merchant flows | B2B Edition (approval workflows, POs); native graduation |
The honest lift: this is not a build-from-zero. It is taking a behavior-verified POC to GA, where the gating item is sponsoring the BC Payments partner-track rail, not writing the product.
Risk
- BC Payments rail (partner-track). The GA charge path depends on partner-track access to BC's first-party rail. A real dependency to size and sponsor; the architecture already routes through it gateway-agnostically, so it's an enablement risk, not a redesign.
- Marketplace-first vs. native. Ships as a marketplace app today. Going fully native — a deeper BC platform integration — is a future BC org decision, not a commitment. If that call is ever made, it carries a bounded, known ~30% rewrite cost on the app side. That's a hedge cost ceiling, not a current liability.
- Pricing/packaging is unvalidated. Out of engineering scope, flagged so it isn't mistaken for settled.
The ask
Review the architecture and the live sandbox POC. Decide whether to back the engineering to take a verified POC to GA — with the BC Payments partner-track rail as the gating dependency to sponsor, and B2B Edition as the Phase-2 scope.