Strategy
Strategic decisions.
What we've committed to, how delivery sequences, what success looks like, and the open forks still in play. The full product spec lives in the PRD.
Product thesis
There is no subscription product that is BC-first, mid-market-ready, and unified with BC Payments. Every existing subscription app on BigCommerce forces merchants to run a parallel payment relationship outside their BC Payments account. We close that gap: a marketplace app where orders are BC orders and payments settle through BC Payments — one dashboard, one payout, one payment relationship.
For the Mustang conversation (BigCommerce's >$5M-GMV WooCommerce migration push) specifically, subscriptions are the anchor keeping >$5M-GMV merchants on Woo. Removing that anchor is the migration unlock — the commercial answer is not "cheaper than free Woo Subscriptions," it is "one payment relationship instead of two."
Ratified decisions
Marketplace-first, native-ready
Ships as a BC marketplace app — marketplace is the destination, not a waypoint. Designed for native-readiness from day one. The ~30% Substrate-A (the Cloudflare-Workers implementation layer) write-off is bounded and accepted: fork-revisit conditions (positioning shift, pod staffing, platform boundaries, cadence) are tracked and reviewed quarterly.
BC Payments as primary processor; Stripe as alternate
BC Payments (powered by PPCP — PayPal Commerce Platform) is the canonical charge rail. No raw card data in the app — BC-vault stored instruments handle PCI scope. Stripe remains a fully-supported adapter for merchants not on BC Payments. The dual-path ships at MVP; no merchant is forced to switch.
Delivery plan
Sequencing follows a ratified four-tier cohort model (see the decision record). The Phase labels below map to Tier α / β / γ+δ respectively.
Phase 1 / Tier α
Core loop
- ·OAuth install + App Extensions (Products, Orders, Customers)
- ·BC Payments adapter (primary) + Stripe adapter (alternate)
- ·Billing engine — dunning, scheduling, retry
- ·BC order creation on every successful charge
- ·Subscriber portal: skip, swap, pause, reschedule, update PM
- ·Merchant dashboard: MRR, exceptions, reconciliation link
- ·Stencil storefront widget + headless SDK
Phase 2 / Tier β
Platform depth
- ·Braintree standalone + Authorize.net adapters
- ·Multi-Storefront / channel-scoped plans
- ·Customer-group–scoped pricing
- ·Prepaid / fixed-term subscriptions
- ·Migration tooling (import from Recharge, PayWhirl, Bold)
- ·Klaviyo + Ortto integrations
- ·Cancel-flow A/B testing + intervention analytics
Phase 3 / Tier γ+δ
Enterprise
- ·B2B Edition (company accounts, approval workflows, PO payment)
- ·Build-a-box / bundle subscriptions
- ·Usage-based billing primitive
- ·Advanced segmentation (RFM retention campaigns)
- ·White-label portal (custom domain, full theming)
- ·International BC Payments regions as BC rolls out
Success criteria (MVP exit)
Engine-works metrics — pipeline reliability:
- 10 paying merchants onboarded
- 1,000 active subscriptions across the platform
- 95%+ charge success rate (p50), 90%+ (p95)
- 85%+ dunning recovery rate within 7 days
- <1% reconciliation drift (charges with inconsistent state between us ↔ BC ↔ processor)
- Median subscriber self-service resolution: no merchant support ticket required for skip/swap/pause/PM-update
- Median merchant exception-queue time to resolution: <1 business day
Differentiator metrics — wedge validation:
- Path A mix
[target]: ≥60% of MVP merchants on BC Payments adapter. Validates the BC-Payments-unification thesis. <60% means the pitch isn't landing or the path isn't smooth enough. - Onboarding step count: ≥30% fewer steps end-to-end (install → first subscription enabled) vs Recharge baseline. Empirical, not anecdotal — requires a one-off competitive audit before MVP launch to set the baseline. Validates the "lowest-friction install" claim from §3.
- PM-update friction: ≤2 clicks to update payment method across N subscriptions for a customer with N>1. Validates D5 (PRD-COMPANION D17 / customer-level
payment_customer_ref) — the cross-sub PM update UX that differentiates against Recharge's per-sub flow.
These are exit criteria, measured retrospectively to declare MVP successful — not blockers for shipping.
Open strategic forks
Delivery shim path — platform-collaborative as peer to marketplace and native
A third sibling delivery lane the marketplace-vs-native binary missed: small, typed, additive BC platform extensions that compose with our marketplace app. Three-lane comparison, eight architectural-principles tests, three keystones (Catalog A1, Payments A8, Domain Eventing A15), and the B2B Edition reframe — federated identity is not a shim, it is platform federation work blocked-on-other-team.
Delivery fork — bolt-on app vs. first-class platform citizen
Whether bc-subscriptions ships as a BC marketplace app (current shape) or as a native first-class BC service built directly into BigCommerce's own infrastructure. Triggered by Jordan Sim 2026-05-22 raising B2B Edition as the bolt-on cautionary reference. Contains the native-shape gap matrix and the portability inventory. Extended by the delivery shim path above, which adds a third sibling lane.
Evidence
Not an open question — a sourced, re-derivable record of what's actually been built and verified.
Verified throughput
What was actually built, with every stat traced to a named, re-runnable source — designed via an adversarial plan-then-judge pass specifically to keep vanity metrics off the page.
When something lands here
Strategic-decision artifacts are filed when a question crosses the threshold of "can't be decided by reading code or existing ADRs alone" — typically forks about delivery shape, organizational placement, business model, or BC-platform alignment posture. Each entry pairs a narrative markdown doc with one or more analytical artifacts (gap matrices, inventories, criteria checklists), and surfaces through a [Decision] Hive proposal for synthesis.
docs/strategy/ · repo · team access