1. Context & Scope of the Ask

1.1 What is being commissioned

Kibble & Co. is commissioning a subscriptions and recurring-billing capability, built directly against its existing BigCommerce storefront's platform APIs — its Orders, Customers, Price Lists, and Payments APIs — rather than adopting a third-party subscription application from the BigCommerce app marketplace.

Kibble & Co. has never offered subscription commerce before. It evaluated the marketplace-app path first, and rejected it for reasons specific to how the business already runs: an install step and a second vendor relationship to manage; a second admin surface that staff would have to reconcile by hand against Kibble's own catalog, orders, and customer records; a subscriber portal that would look and feel bolted onto Kibble's storefront brand rather than native to it; and subscription-specific software pricing stacked on top of what Kibble already pays for BigCommerce.

A capability built directly against BigCommerce's own platform APIs removes each of those costs: no separate application to install, no second vendor relationship, subscription orders and subscriber records that live inside Kibble's existing BigCommerce admin, and a subscriber portal built as part of Kibble's own storefront rather than a third party's.

The scope in this package has already been de-risked through a working reference implementation, built against production BigCommerce APIs and covering the end-to-end subscription lifecycle described in the sections that follow. The reference implementation is not the deliverable, and its runtime architecture is not for reuse — treat it as an executable answer key for the written requirements, useful when a requirement reads ambiguously. See 10-reference-prototype.md.

1.2 Market context

Subscription commerce is now a competitive-parity requirement for pet-supply retailers selling consumable and replenishable goods, not a differentiator. A mature ecosystem of specialist subscription applications, sold across commerce platforms generally, has established the baseline feature set — flexible cadence management, self-service customer portals, dunning and retry logic, subscription-aware promotions — that any capability Kibble ships must match or exceed to be credible with a subscriber base that has already used subscription commerce with other replenishment brands.

Kibble & Co. sells directly against that expectation gap today: pet food, treats, and supplements are exactly the consumable categories where subscribers expect a subscribe-and-save option, and Kibble currently has none. Every reorder happens the way a one-time order happens — a subscriber has to come back and buy again, with no cadence, no reminder, and no discount for committing to one.

Detailed feature-by-feature competitive positioning — capability matched against the bar existing native and third-party alternatives already set — is provided in 04-competitive-benchmark.md. This section establishes only the framing an estimator needs up front: the target is not a novel product category. It is parity-or-better against a bar the market has already set.

1.3 Target segments

The delivered capability must serve four segments of Kibble & Co.'s own customer base, each with distinct subscription needs:

Individual subscriber. A single-pet household ordering one product line — most often food — on a recurring cadence. Expects self-serve setup with minimal configuration overhead, and is the most price-sensitive segment toward any added subscription fee.

Multi-pet household. Kibble's primary near-term target. These subscribers run multiple concurrent subscription plans across several product lines at once — different food per pet, plus a supplement or treat cadence — and expect subscription pricing that is aware of Kibble's existing price-list and customer-group segmentation (a standing Rewards-tier discount, for instance) rather than a flat, catalog-blind subscription price.

Retail and wholesale partners. Kibble's existing B2B channel: independent pet boutiques, groomers, and small clinics that reorder core SKUs on standing recurring terms. These accounts purchase by invoice or purchase order rather than card-present checkout, run longer commitment terms, and require the capability to integrate with BigCommerce's B2B Edition company-account and account-hierarchy model rather than with individual consumer accounts.

High-volume regional accounts. Kibble operates more than one storefront channel — its direct-to-consumer site and a separate wholesale channel on BigCommerce's Multi-Storefront capability — and as subscriber volume grows across both, auditable, replayable billing operations become an operational necessity rather than a convenience.

The capability-by-segment mapping — which capabilities are required at which segment tier — is detailed in 02-capability-catalog.md.

1.4 Personas

Four personas define the requirements in this package and recur throughout the sibling documents.

Merchant Admin — Kibble's merchandising and ops lead

• Operates Kibble & Co.'s existing BigCommerce catalog, with existing price lists and customer groups already configured.
• Today, replenishment is handled by hand: staff track high-frequency reorder customers off exported order data and send email or phone reminders to reorder. There is no recurring-order capability at all.
• Pain: manual reorder tracking doesn't scale past a small list of customers, and none of it shows up in Kibble's own BigCommerce order data — the revenue impact of lost replenishment is invisible.
• Success: every subscriber appears as an ordinary BigCommerce customer with a recurring order cadence — nothing separate to reconcile, nothing separate to learn.

Subscriber — Kibble's end customer

• A logged-in Kibble & Co. customer.
• Expects a single self-service portal covering the full range of subscription adjustments: skip the next order, swap a product, change cadence, pause, update payment method, reschedule — all without opening a support ticket.
• Pain: most subscription portals feel dated and visually disconnected from the storefront brand the subscriber is otherwise shopping on.
• Success: a portal experience indistinguishable, in look and feel, from the rest of Kibble's storefront.

Developer — implementation partner or in-house engineer

• The agency partner delivering this engagement, or a Kibble in-house engineer maintaining it afterward.
• Needs a documented, stable API surface and webhooks covering the full subscription lifecycle, integrating cleanly against Kibble's existing BigCommerce catalog and customer data with no legacy subscription system to migrate off of.
• Success: able to build and maintain Kibble's subscriber-facing experience within a short, bounded engineering cycle rather than an open-ended integration effort.

Support / Ops — Kibble's customer service and reconciliation team

• Reconciles failed renewals, handles cancellation requests, and processes refunds.
• Needs a single operational view of any given subscriber: upcoming charge, recent order history, payment method health, and current dunning or retry state.
• Success: resolves a failed renewal, or a cancellation request, entirely from that one view — without switching between multiple tools.

1.5 Product principles & quality bar

Four principles set the quality bar the delivered solution is measured against, independent of implementation approach:

• Built on the platform, not bolted onto it. The capability integrates through Kibble's existing BigCommerce admin and storefront rather than operating as a separate purchased tool. There is no separate application for Kibble's team to install, no separate vendor relationship to establish, and no separate admin surface that has to be reconciled against Kibble's core store.
• Zero raw-card handling in subscription components. The subscription capability never receives, transmits, or stores unencrypted payment card data. Every recurring charge executes against a payment instrument held in BigCommerce's own payment vault — there is no parallel, vendor-operated card store. Delivered as a build directly against the platform's payment surface, the capability sits inside BigCommerce's existing PCI DSS service-provider compliance program via the BigCommerce Payments API's Payment Access Tokens; containment keeps the assessment delta small, it does not remove the obligation.
• Subscription state stays consistent with platform state. Subscription records for Kibble's subscribers must remain continuously consistent with BigCommerce's own order and customer records. There is no shadow ledger of subscription activity that can drift from the platform's system of record.
• Experience parity-or-better. Both Kibble's admin experience and its subscriber self-service experience must meet or exceed the standard already set by mature specialist subscription applications in market today. See 04-competitive-benchmark.md for the specific bar this is measured against.

1.6 Non-goals for the initial release

The following are explicitly out of scope for the initial release, to bound estimation:

• Not a general billing platform. Usage-based subscription pricing — a consumption-based charge computed within a subscription — is part of Kibble's long-term capability roadmap but sits in deferred scope for this engagement (see 08-scope-boundary-and-engagement-model.md §8.3 — do not price it into this bid). Standalone invoicing and general-purpose metering-as-a-service are out entirely.
• Not a loyalty or rewards engine. Subscriptions may integrate with Kibble's existing customer-group-based Rewards program; the initial release does not build a new rewards economy (no points, tiers, or earn-multipliers). The sole carve-out is a narrow store-credit incentive surfaced at the moment a subscriber initiates cancellation, intended to retain a subscriber who is actively leaving.
• Not a CRM or marketing automation platform. The capability emits events for consumption by Kibble's external marketing and CRM systems; it does not replicate their functionality.
• Not a custom checkout replacement. Subscription capture layers onto Kibble's existing native BigCommerce checkout experience rather than replacing it.
• Not a tax or shipping calculation engine. Tax and shipping determination are delegated to Kibble's existing native and third-party tax and shipping capabilities.
• Not a payment processor. The capability integrates with Kibble's existing payment processor relationship; it does not take on PCI-scope responsibility for card data itself.

1.7 How to use this package

This package is sequenced so an estimator can move from what must be built (this section, and 02–04) to how it must integrate with the platform (05–06) to how the work breaks down and is bid (07–09). The reference prototype (10) is available throughout as an executable specification of intended behavior — not as source code or a runtime architecture to port. The table below maps each sibling file to the question it is written to answer.

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.