---
status: demonstration
audience: public-demonstration
fixture: kibble-and-co (fictional)
---

# 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:

| Domain | Epics | Description |
|---|---|---|
| Onboarding | 1–3 | Turning the capability on for Kibble's store, connecting a payment processor, and — if Kibble later needs it — bringing subscribers across from a prior subscription app |
| Catalog | 4–7 | Making Kibble's existing BC products subscribable: plan design, pricing, advanced subscription types, and which channels or customer groups a plan applies to |
| Purchase | 8–9 | The storefront moment a shopper picks "subscribe & save" over a one-time buy, carried through cart and checkout |
| Billing | 10–13 | Recurring charge execution, decline recovery, refunds, and reconciliation against the processor and BC order records |
| Orders | 14–16 | Turning a successful renewal charge into a normal BC order Kibble's fulfillment process already knows how to handle |
| Self-Service | 17–20 | The subscriber portal: skip/swap/pause/cancel, payment and address management, and retention offers at cancellation |
| Operations | 21–22 | Kibble's internal dashboard, KPIs, exception handling, and support-desk tooling for one-off subscriber requests |
| Commerce | 25–26 | Subscription-aware promotions and the rules governing which products or customer segments can subscribe |
| Platform | 23, 24, 27 | Notifications, optional wholesale/B2B account support, and a developer-facing API/webhook surface |
| Trust | 28 | Compliance, audit trail, and data-handling controls |

**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:

| Phase | Stories | Share |
|---|---|---|
| MVP | 104 | 47.7% |
| P1 | 33 | 15.1% |
| P2 | 52 | 23.9% |
| P3 | 29 | 13.3% |
| **Total** | **218** | **100%** |

By domain, the same corpus breaks down as:

| Domain | Epics | Stories | MVP | P1 | P2 | P3 |
|---|---|---|---|---|---|---|
| Onboarding | 1–3 | 21 | 12 | 1 | 7 | 1 |
| Catalog | 4–7 | 30 | 9 | 7 | 10 | 4 |
| Purchase | 8–9 | 12 | 8 | 2 | 1 | 1 |
| Billing | 10–13 | 27 | 17 | 2 | 8 | 0 |
| Orders | 14–16 | 18 | 8 | 4 | 5 | 1 |
| Self-Service | 17–20 | 29 | 20 | 3 | 3 | 3 |
| Operations | 21–22 | 17 | 6 | 6 | 4 | 1 |
| Commerce | 25–26 | 21 | 6 | 6 | 4 | 5 |
| Platform | 23, 24, 27 | 36 | 15 | 1 | 7 | 13 |
| Trust | 28 | 7 | 3 | 1 | 3 | 0 |
| **Total** | | **218** | **104** | **33** | **52** | **29** |

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](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](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](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.