2. Capability Catalog & Release Phasing

2.1 Overview

Kibble & Co. is commissioning a subscriptions capability for its existing BigCommerce storefront — recurring auto-ship of dog food, cat litter, and other consumable pet supplies, built as native functionality on the platform rather than a third-party app install. The scope is organized into 10 capability domains spanning 28 epics and 218 user stories. Every story rolls up to exactly one epic, and every epic rolls up to exactly one domain — the mapping is fixed and used consistently across this package (work breakdown, journeys, estimation scaffold).

The domains, in rough dependency order from store setup through platform depth:

Release-phase semantics. Every story in the underlying requirements corpus carries one of four phase labels, which set release-scope intent for this bid rather than a strict delivery calendar:

• MVP — initial release; the smallest end-to-end loop that lets Kibble sell and successfully bill a real recurring subscription on its live store.
• P1 — fast-follow; extends MVP breadth (additional subscription types, order bundling, faster support tooling) shortly after Kibble's initial launch.
• P2 — platform depth; plan scoping, multi-processor support, migration tooling, and richer merchant-facing controls, once the MVP loop is proven.
• P3 — expansion; wholesale/B2B account support, advanced segmentation, and the deepest developer-platform and promotions work — capability Kibble may want later but is not commissioning up front.

Illustrative — invented for this demonstration. A fixed-scope bid against this catalog might plan roughly 12 weeks for MVP, 9 weeks combined for P1+P2, and 11 weeks for P3. These are planning-sanity-check numbers for the estimator reading this package, not a delivery commitment — actual sequencing and duration depend on the vendor's own estimate.

2.2 Scope summary

Computed from the story-level phase tags across the full 218-story corpus:

By domain, the same corpus breaks down as:

The domain sections in §2.3 describe each row. Just under half the corpus is MVP — consistent with Kibble wanting a real, billable subscription loop live on day one, with everything else sequenced to follow.

2.3 Capability domains

Onboarding (Epics 1–3)

Covers everything Kibble does before the first subscription can be sold: turning the capability on for its store, connecting a payment processor capable of merchant-initiated-transaction renewals, and — if Kibble is coming from a prior subscription app — migrating existing subscribers and schedules onto this build. Onboarding is a one-time setup flow, not an ongoing operational surface. Processor connection is the hard dependency for every downstream billing capability: no processor, no renewals. Migration is scoped as an optional accelerant, not a requirement, since Kibble may be standing up subscriptions for the first time rather than switching platforms.

Because Kibble is commissioning native functionality rather than installing a third-party subscriptions app, Epic 1's enablement stories are stated in native terms throughout this package — a marketplace-app equivalent would cover the same functional ground. The prototype and its walkthroughs are in 05-platform-integration-contract.md §5.2.10.

Why this phase boundary, for Kibble: enablement and processor connection are MVP-complete because nothing else in the catalog works without them. Migration (Epic 3) is deliberately sequenced past MVP — Kibble can launch subscriptions net-new without it, and the depth only matters if Kibble decides to consolidate an existing subscriber base onto this build.

Catalog (Epics 4–7)

Covers turning an existing Kibble product — a bag of kibble, a case of litter — into a subscribable offer without duplicating SKUs: enabling subscription on a product, designing plans (interval, pricing strategy, trial/commitment terms), advanced subscription types beyond a simple recurring interval, and scoping which channels, customer groups, or price lists a plan applies to. Pricing strategy can reference Kibble's existing BC pricing structures directly, so subscription pricing never becomes a second source of truth. Scoping is the domain's most business-model-sensitive piece — it is what would let Kibble restrict or vary a plan by channel or customer group if it ever sells through more than one storefront or price list.

Why this phase boundary, for Kibble: single-product plan design (Epics 4–5) is MVP-weighted because it is the whole point of the build — a shopper needs to be able to subscribe to a bag of food on day one. Scoping (Epic 7) lands entirely at P2 because Kibble launches with one storefront and one customer base; channel- and group-level plan variation only matters once Kibble's selling model gets more complex than that.

Purchase (Epics 8–9)

Covers the storefront moment a Kibble shopper chooses "subscribe & save" over a one-time purchase, and that choice surviving into checkout. Includes the on-page subscription selector (interval choice, pricing preview) and the mechanism that carries subscription intent from cart through to order creation. This domain is intentionally thin and MVP-heavy: it is the shopper-facing tip of a much larger billing and fulfillment build underneath.

Why this phase boundary, for Kibble: both epics are MVP-majority because without them there is nothing to bill — a shopper has to be able to choose and confirm a subscription before any of the billing or fulfillment machinery has anything to do.

Billing (Epics 10–13)

The recurring-revenue engine: scheduling and executing charges against a stored payment method, recovering from declined charges through a configurable retry sequence, handling refunds/credits/manual charges, and reconciling billing state against the processor and BC order records. This is the domain that decides whether the subscription actually works for Kibble — a failure here is a failed or duplicated charge against a real customer, the highest-consequence failure mode in the whole build.

Why this phase boundary, for Kibble: this domain is MVP-heavy across the board (17 of 27 stories) and has no P3 content at all. Correct billing isn't a feature Kibble can defer — it's the day-one requirement the whole business case rests on.

Orders (Epics 14–16)

Covers what happens after a renewal charge succeeds: generating a native BC order from the charge (so Kibble's existing fulfillment tooling sees a normal order), recalculating inventory, tax, and shipping at renewal time (since catalog and tax conditions can change between cycles), and bundling multiple due subscriptions for the same subscriber into a single order where it makes sense. Order generation is the seam where this build hands off to BC's existing commerce and fulfillment machinery Kibble already runs on.

Why this phase boundary, for Kibble: order generation and recalculation (Epics 14–15) are MVP because a renewal that doesn't produce a fulfillable order isn't a working subscription. Order bundling (Epic 16) is fast-follow rather than MVP — it only matters once enough subscribers have multiple concurrent subscriptions (food plus litter, say) for bundling to save Kibble on shipping.

Self-Service (Epics 17–20)

The subscriber-facing portal: authenticated access, lifecycle actions (skip, swap, pause, reschedule, cancel), payment method and address management, and structured churn-prevention flows presented at cancellation. This is the domain most directly tied to subscriber retention for Kibble — a cancellation flow that offers a relevant alternative before letting a subscriber leave is core to the subscription business case, not a nice-to-have.

Why this phase boundary, for Kibble: this is the most MVP-concentrated domain in the whole catalog (20 of 29 stories). A subscriber who can't skip a shipment or update a card is a subscriber who cancels instead — self-service is table stakes for Kibble at launch, not something to add later.

Operations (Epics 21–22)

The internal, merchant- and support-facing surface: a dashboard with subscription KPIs and an exception queue for failed renewals or reconciliation drift, plus manual subscription creation and customer-service tooling for one-off subscriber requests outside the self-service portal. This is where Kibble's own staff and support agents work once the storefront and billing loop are running.

Why this phase boundary, for Kibble: a baseline dashboard (Epic 21) is MVP-majority — Kibble's staff need to see that renewals are working from day one. Manual/CS tooling (Epic 22) is weighted to P1 (5 of 9 stories) because it's most useful once Kibble's support desk has real exception volume to react to, which only exists after launch.

Commerce (Epics 25–26)

Covers subscription-aware promotions and discounts, and the rules that determine which products, variants, or customer segments are eligible (or excluded) for subscription. This is where merchandising logic lives — it decides who can subscribe to what, at what price, under what promotional terms, distinct from the base pricing mechanics owned by Catalog.

Why this phase boundary, for Kibble: both epics spread across all four phases rather than clustering at MVP, because promotions and eligibility rules only pay off once Kibble has a live subscriber base to segment and market to. Eligibility (Epic 26) is where the deepest rule logic accumulates, alongside Scoping, the developer platform, and compliance — the four areas of this catalog that skew toward capability Kibble would grow into rather than launch with.

Platform (Epics 23, 24, 27)

Covers three cross-cutting capabilities that sit outside the core purchase-to-order loop: transactional notifications and third-party marketing-platform integrations (Epic 23), optional wholesale/B2B account support — company accounts, approval workflows, purchase orders as a payment method (Epic 24), and a developer-facing REST API, webhook, and SDK surface (Epic 27). These three are grouped because each serves an external actor — a subscriber's inbox, a wholesale buyer, or a developer — rather than a step in Kibble's core storefront workflow.

Why this phase boundary, for Kibble: notifications (Epic 23) is MVP-heavy for the base transactional set — a subscriber needs to know a renewal is coming and a charge went through, from day one. B2B account support (Epic 24) is deferred entirely to P3: Kibble sells direct to consumers today, and wholesale accounts for groomers, boarding facilities, or clinics are expansion, not launch scope — every one of its 11 stories sits at P3, with nothing earlier. The developer platform (Epic 27) is similarly back-weighted, since API/webhook consumption only matters once Kibble (or a partner) needs to integrate something the storefront doesn't already cover.

Trust (Epic 28)

Covers compliance, audit trail, and data-handling controls that apply across the entire capability set: what gets logged, how long data is retained, and what evidence exists for Kibble's own regulatory and contractual obligations around subscriber payment and personal data. Trust is a single epic rather than a cluster because its stories cut across every other domain's data rather than owning a workflow of its own.

Why this phase boundary, for Kibble: an MVP baseline audit trail ships with launch; the deeper compliance controls (P2) build out once the subscription program is running and generating real data to govern. Trust is one of the four areas in this catalog — alongside Scoping, Eligibility, and the developer platform — that concentrate past MVP rather than at it.

2.4 Reading further

• Per-story detail (acceptance criteria, dependencies, effort sizing) is in 07-work-breakdown.md.
• Story-level acceptance criteria are intentionally excerpted rather than reproduced in full within this package — the phase and epic shape shown here is the exhibit; the underlying requirements corpus is not.
• End-to-end user journeys that traverse multiple domains are in 03-user-journeys.md.

Kibble & Co. is a fictional demo merchant. This package is an independent demonstration by Nino Chavez of a scoping method — not a BigCommerce product, and not a real procurement.