Strategy & Market Context¶
Generated from a canonical source
This page is a read-only projection of STRATEGY.md.
Edit the canonical file, then run npm --prefix tools/project-knowledge-derive run derive.
Status: Draft
Owner: TBD
As-of date: 2023-Q1 (source research date); this doc consolidates and extends through 2026-04
Refresh cadence: Re-audit partner / platform findings every 2 quarters, or sooner on any BC Payments release affecting the subscriptions surface
Related: PRD.md (what), BRD.md (requirements), ARCHITECTURE.md (how), PRD-COMPANION.md (decisions), BRD-OPEN-QUESTIONS.md (open items)
What this doc is¶
Evidence and framing that backs the positioning choices in PRD.md. Not a decision record — product decisions live in PRD.md and PRD-COMPANION.md. Not a roadmap — phasing lives in PRD §12.
Read this when you want to know why we're building what we're building, or to cite primary-source research in exec/sales/internal narrative work. When this doc and PRD.md disagree, PRD.md wins and this doc needs an update.
What this doc is not¶
- Not a spec. No API contracts, data models, or acceptance criteria.
- Not a competitive tear-down with current product capabilities. The competitive content here is positioning-level; detailed capability comparisons live in Sales Engineering collateral.
- Not evergreen. Several sections cite Q1 2023 research that has known staleness — see Known staleness at the end.
Market context¶
Why subscriptions matter for BigCommerce¶
BigCommerce merchants operate in the mid-market / ENT band where subscription commerce is both a growth motion (higher LTV, recurring revenue predictability) and a defensive one (competitive parity with Shopify subscription ecosystem). Subscription revenue share of commerce spend has grown consistently through 2020–2025; the Product Pack cites Recurring Products subscriptions as ~32% of all subscription purchases globally (Product Pack §2.3), with the fastest-growing segments being Build-a-box and Convertible models.
Why a BC-blessed default subscriptions app, and why now¶
For most of BC's history, subscriptions have been an app-partner domain — Recharge, Bold, Sticky.io, MiniBC, Rebillia, Ordergroove, Chargify. The app-partner model created predictable friction: checkout bypass (partner checkouts replacing BC's), shopper-portal fragmentation, payment-vault gaps, and a ceiling on the quality-of-experience BC could offer its own merchants. BC's own Q1 2023 discovery (Product Pack §3.2.3) rated merchant quality-of-experience on subscriptions at 3.⅖ across all plan tiers, with only 10% of merchants reporting zero issues. Checkout and Shopper Management dominated pain.
The gap is durable. The answer is not "BC builds subscriptions natively"; the answer is a high-quality marketplace app that fills the gap, built to BC's internal patterns, positioned as the BC-blessed default. bc-subscriptions is that app. Three pieces of evidence anchor this framing:
- BC's documented stance is that third-party apps own subscriptions. BigEng's payment-API RFC explicitly carves subscription orchestration to 3P apps (PROJECT-1986; the OrderGroove integration trail in
rfcs/payments/payment-api.mdis the canonical citation). The internal direction is not "displace 3P subscriptions" but "make the partner-built subscription surface excellent." - The platform already exposes a permission shape for partner-owned subscriptions. The
account_subscriptions_readpermission scope atbigcommerce/permissions config/defaults/policies.yml:40is the precedent — BC has been encoding "a partner-built subscription product reads from this account" as a first-class platform concept for years. Partner-track subscriptions are a designed-in shape, not a workaround. - The ADR-0029 ratification names this posture explicitly — "marketplace destination, not waypoint" — and treats native-readiness as a design constraint (BigEng wire conventions, AuthPrincipal envelope, store_hash partitioning) so that if a graduation conversation ever opens, the lift is tractable. See
docs/decisions/0029-marketplace-first-native-ready.mdfor the canonical record.
BC Payments (launched March 2026) is the structural change that makes a high-quality subscription product on top of BC viable. It closes several of the friction points the Product Pack documented — a unified payment rail with first-party vault control, webhook coverage for PM changes, and processor-neutral tokenization. The partner app no longer has to bypass BC's checkout or assemble a third-party vault to ship a reliable subscription product; the rails are there. Several of the app-partner limitations cited in the Product Pack may already be obsolete post-BC-Payments; see Known staleness.
Primary research — 74-merchant survey¶
Source: Product Pack §3.2.3, p.34. Internal BigCommerce survey, Q1 2023.
Headline findings:
- Quality score 3.⅖ across all plan tiers. No tier scored above 3.6.
- 10% of merchants report zero issues. The other 90% reported multiple.
- Top pain stages: Checkout (capture + conversion); Shopper Management (portal, PM updates, pause/resume, cancel).
- Secondary pain: analytics / LTV visibility; failed-renewal recovery.
Interpretation. The pain concentrates at the two stages where app-partners are weakest structurally — checkout (because they bypass BC's) and shopper management (because their portals are generic across all merchants they serve). A BC-native engine owns both stages end-to-end, which is precisely where the quality ceiling is lowest today.
Caveat. Survey predates BC Payments. The distribution of pain stages is likely durable; the absolute severity at Checkout may have compressed post-March-2026.
Primary research — app-partner friction¶
Source: Product Pack pp.25–32. Direct partner interviews + SE-attributed observations.
The following partner-specific friction points are documented in the source. Each is tagged with an audit flag per PRD-COMPANION.md D12: [AUDIT] means the friction may be resolved by BC Payments and needs validation before external citation; [DURABLE] means the friction is platform-shaped and unlikely to have changed.
Framing note. bc-subscriptions specifically does not inherit these friction points. We capture cleanly through BC's own checkout (no bypass), use BC Payments as the unified vault and processor rail (no partner-side vault gap), and ship a subscriber portal native to BigDesign + the merchant's own storefront surface (no portal fragmentation). The table below is the partner-landscape baseline we are not — read it as the "before" picture, with bc-subscriptions as the documented "after."
| Partner | Friction | Audit flag |
|---|---|---|
| Recharge | Bypasses BC checkout; cites vault gaps, missing PM-change webhook (feature request PROJECT-4237) | [AUDIT] — BC Payments may close this |
| Recharge | Requires third-party address validation (Addrexx) because BC postal-code validation is insufficient | [DURABLE] — not a BC Payments scope |
| Chargify | Limited to OPC; redirect-checkout limitations in ENT tier | [AUDIT] |
| Rebillia | Built on Legacy Checkout (LCO), which BC cannot deprecate because of this dependency | [DURABLE] |
| Bold | Redirect checkout; ENT SE feedback rates it poorly | [AUDIT] |
| MiniBC | Widely used at ENT tier; subscription-model coverage is limited | [DURABLE] |
| Sticky.io | SMB-tier only; narrow subscription-type coverage | [DURABLE] |
| Multiple | Bundle taxation applied at parent SKU only; mixed-tax-code bundles break (ATX merchant) | [DURABLE] — BC tax service behavior, not payment |
Interpretation. The [DURABLE] friction points represent real, present-tense opportunities for a BC-native engine. The [AUDIT] points are the ones to validate against BC Payments before citing externally (this is the substance of D12).
Primary research — SE rankings by tier¶
Source: Product Pack pp.29–31. Sales Engineering internal rankings.
Enterprise tier: 1. Ordergroove — "closest to what ENT wants but expensive" 2. MiniBC — "reliable, limited model coverage" 3. (tie) Bold / Recharge — penalized for redirect checkouts and ENT-support gaps
SMB tier: 1. Recharge — strong SMB fit, accepted checkout bypass 2. MiniBC 3. Sticky.io 4. Paywhirl 5. Rebillia — penalized for LCO-only and narrow coverage
Most popular subscription model by tier: - ENT: Recurring Products only - SMB: Recurring + Convertible + Build-a-box (broader mix)
Interpretation. Our positioning target sits in the gap between Ordergroove-expensive-ENT and Recharge-SMB-shaped. Mid-market merchants who outgrew Recharge's fit but can't justify Ordergroove pricing are the clearest beachhead. This is consistent with PRD §5 persona selection and supports the ENT-growth-wedge framing in PRD-COMPANION D14.
Subscription-type taxonomy¶
Source: Product Pack §2.3.
| Model | Industry fit | Approx. share | Our coverage |
|---|---|---|---|
| Recurring Products | Consumables, vitamins, pet, coffee, personal care | ~32% of all subscription purchases | prototypes/advanced-subs + core |
| Convertible | Equipment-with-refills (razors, printers) | Growing | prototypes/advanced-subs/prepaid adjacent |
| Build-a-box | Meal kits, curated collections | Fast-growing SMB | prototypes/advanced-subs/BuildABox |
| Curated | Stylist-chosen, replacement on cadence | Niche | Covered by bundling + build-a-box |
| Monthly Club | Wine, book-of-the-month | Mature, flat | Covered by recurring |
| Exclusive | Access-only (community, content) | Rising | prototypes/advanced-subs/Membership + D1 Entitlement |
| Brick-and-mortar | Gym, on-premise service | Small in BC context | Out of scope |
Insight surfacing D14 (ENT wedge). Membership/access use cases (the "Exclusive" row) were raised only by Enterprise merchants in the research — Career Step, St John Ambulance, Fitness First/Debit Success (Product Pack p.39). This is the evidence base for promoting membership to an explicit positioning pillar.
Competitive framing¶
App-partner landscape: Recharge, Bold, Sticky.io, MiniBC, Rebillia, Ordergroove, Chargify. Each has a tier sweet spot (above) and characteristic limitations.
Platform competitors: Shopify (native subscription APIs + subscription app ecosystem) is the primary competitive reference. Magento, SFCC, Commercetools are secondary — the Product Pack's §3.1 competitor matrix on these is empty (see What's missing from the source), so claims in this space should be sourced independently before citation.
Our differentiated claim. A BC-native engine that (a) owns checkout capture without bypass, (b) unifies on BC Payments as the processor rail, © offers merchant-first admin UX aligned with BigDesign, and (d) — conditional on D14 — positions membership/access as the ENT growth wedge.
What we're not claiming. We are not a general-purpose subscription platform. PRD-COMPANION D10 explicitly rejects the platform-neutral commerce-adapter abstraction — depth on BigCommerce is the moat, not breadth across platforms.
ICP and segment fit¶
Primary ICP: BC mid-market and ENT-tier merchants running or about to run subscription models, currently using Recharge, Bold, MiniBC, or Rebillia and hitting friction ceilings. Secondary: new BC merchants launching subscriptions who would otherwise install an app-partner.
Migration ICP: The Rebillia-on-LCO installed base is a distinctive migration target because their current setup blocks BC's own Legacy Checkout deprecation (Product Pack p.2). Whether we actively target this segment is PRD-COMPANION D15's open question.
Not-ICP: Pure-SaaS / entitlement-only merchants (no physical fulfillment) — the Product Pack's strategic sections are silent on this segment, our PRD §16.1 rejects the Invoice-as-first-class model that pure-SaaS needs, and D6 reaffirms that positioning. This segment is served better by Stripe Billing / Chargebee and we don't compete for it.
Positioning thesis — one-liner¶
A BC-native subscription engine that captures cleanly, bills reliably, and gives merchants and shoppers an experience that BigDesign-native apps are supposed to have.
Elaborated in PRD §3 pillars. D14 proposes a 4th pillar (membership as ENT wedge) — if accepted, this line expands accordingly.
Evidence-backing map¶
This doc substantiates the following claims elsewhere:
| Claim | Source in this doc | Appears in |
|---|---|---|
| App-partner pain is real and quantifiable | 74-merchant survey (3.⅖) | PRD §2.1–2.2, BRD Epic 1 |
| Checkout + Shopper Management are the pain concentrations | Survey; §3.2.3 | PRD §6.4, PRD §9.x, BRD Epic 17 |
| Mid-market sits in the Ordergroove/Recharge gap | SE rankings by tier | PRD §5 personas |
| Membership/access is an ENT-only signal | Product Pack p.39 | PRD-COMPANION D14, PRD §12 Phase 3 |
| Bundle tax at mixed codes breaks | ATX merchant, Product Pack p.31 | BRD Epic 16, PRD-COMPANION D13 |
| Address validation is a latent reliability cliff | Recharge → Addrexx, Product Pack p.27 | PRD-COMPANION D16, PRD §13 risks |
| LCO compatibility is a TAM question | Product Pack p.2 | PRD-COMPANION D15 |
| BC Payments is the enabling platform shift | External; BC Payments release notes March 2026 | PRD §3, PRD §6.2 |
What's missing from the source¶
The Product Pack is an incomplete artifact. The following sections are empty placeholders in the source (Product Pack pp.42–44):
- §3.1.1–3.1.5 — competitor matrix for Shopify, Magento, SFCC, Commercetools
- §4.2 — target audience
- §4.3 — product vision
- §4.6 — pricing and packaging
- §5 — metrics
- §6 — next steps
Implication for this doc. Pricing, packaging, tier structure, and formal target-audience segmentation are not backed by the Product Pack — they are our own extension. PRD §12–14 advances these dimensions beyond what the source contains; where this doc cites pricing/packaging, it's sourced from the PRD, not from BC's own research.
Known staleness¶
Q1 2023 research ages in these dimensions:
- Partner capability quotes — several [AUDIT] items may be resolved by BC Payments (March 2026). Audit before external citation. D12 tracks the audit as an open item.
- SE rankings by tier — partner product roadmaps move. The 2023 ranking reflects tooling state at that time; re-confirm with SE before using in sales collateral.
- Bundle taxation — dependent on BC tax service behavior, which has its own release cadence. Verify current behavior before citing as a present-tense limitation.
- Subscription-type industry shares — the 32% figure for Recurring Products is plausible but the source is unspecified in the Product Pack. Re-source against a dated analyst report (Mintel, Recurly, or Zuora research) before external use.
Refresh triggers: - Any BC Payments release affecting subscriptions (webhooks, vault, PM updates) - Any BC tax service release - BC internal re-run of the 74-merchant survey (recommend every 12 months) - Any partner acquisition or major release in the app-partner competitive set
Glossary¶
- LCO — Legacy Checkout. BC's older checkout surface; kept live because Rebillia depends on it.
- OPC — Optimized One-Page Checkout. BC's current checkout surface; assumed for our engine.
- PM — Payment Method.
- ICP — Ideal Customer Profile.
- SAQ-A — PCI DSS Self-Assessment Questionnaire tier for merchants that fully outsource card handling.
- SE — Sales Engineering.