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

# 10. Reference Prototype

## 10.1 What exists

Kibble & Co. operates a public demonstration fleet showing the subscription
capability running today, live on the open web. It is not slideware:

- **Full purchase loop, observable end to end.** Browse the storefront
  (storefront.bcsubs.app, aisles.bcsubs.app), choose an Auto-Refill
  subscribe-and-save cadence, and complete checkout against Kibble & Co.'s
  own live catalog — a curated range across eight categories from five named
  independent pet brands.
- **Full subscriber lifecycle, observable end to end.** From the same
  storefront: skip a delivery, swap a product, pause, or change the delivery
  cadence — the self-service actions a subscriber uses after the first
  purchase, without contacting support.
- **Recurring billing and merchant operations, demonstrated but not directly
  watchable.** That half of the system runs behind the storefront, not in
  front of it. marketing.bcsubs.app's lifecycle explainer (subscribe, charge,
  manage, recover, report) and its three narrated video walkthroughs —
  merchant setup, day-to-day merchant operations, and the subscriber purchase
  journey — show what renewals, dunning, and the merchant side look like.

A companion demonstration, askbc.ninochavez.co, shows an AI-powered
store-assistant pattern built on BigCommerce. It is a public product page
rather than a live embedded session, and it is not part of the subscriptions
purchase loop above — it is included because it is part of the same public
fleet and speaks to the same platform-native build quality.

ninochavez.co/demos carries the build record: written, session-by-session
accounts of how the fleet above was built, plus a set of standalone
technique write-ups pulled from that work.

All of this is reachable directly. No login, request, or credential stands
between an estimator and any of it. What an estimator sees at these addresses is
the thing itself, not a description of it.

## 10.2 Role in the engagement

The fleet is an **executable reference specification**, not a codebase to
extend:

1. **Behavior oracle.** When a bid-preparation question takes the form "what
   should happen when…", the fastest answer is to run the flow on the live
   storefront and watch. The written acceptance criteria remain the
   contractual authority (see
   [08-scope-boundary-and-engagement-model.md](08-scope-boundary-and-engagement-model.md));
   the demonstration is the fastest way to understand them.
2. **Feasibility signal, not feasibility proof.** The MVP journeys this
   package describes
   ([03-user-journeys.md](03-user-journeys.md)) are not hypothetical — the
   subscribe-and-save purchase and the subscriber self-service actions are
   running today, publicly, against a real catalog. That is weaker than a
   credentialed sandbox with visible billing execution: a public storefront
   demonstrates front-end and purchase-flow behavior, not the billing,
   dunning, or merchant-admin internals a vendor would need to price. Those
   remain estimation judgment calls, priced from the written requirements,
   not something an estimator can watch run.
3. **Estimation aid.** An estimator can explore the storefront and the
   recorded walkthroughs directly, at any hour, before a bid is due — no
   scheduling, no NDA, no request required.

The vendor builds the production system natively on Kibble & Co.'s
BigCommerce store, with their own architecture. The demonstration fleet's
own runtime, code, and internal design are explicitly **not** the target and
impose no constraint on the vendor's solution beyond the behavior itself.

## 10.3 What is available to estimators

Public, unauthenticated, reachable by anyone during bid preparation:

| Surface | What it shows |
|---|---|
| storefront.bcsubs.app, aisles.bcsubs.app | The live Kibble & Co. storefront: catalog, Auto-Refill subscribe-and-save purchase, and subscriber self-service (skip, swap, pause, change cadence) |
| marketing.bcsubs.app | Capability overview, lifecycle explainer, and three narrated video walkthroughs (merchant setup, merchant operations, subscriber purchase) |
| askbc.ninochavez.co | A companion AI store-assistant demonstration on BigCommerce |
| ninochavez.co/demos | The written build record — how the fleet was built, session by session, plus standalone technique write-ups |

## 10.4 What is not provided

- **Source code for reuse.** Whether any of the demonstration fleet's code
  is referenced during the build is a Kibble & Co. decision reserved for
  post-selection; bids must not assume it.
- **Admin or back-office access.** The public surfaces show the storefront
  and subscriber experience; they do not expose merchant dashboards, billing
  configuration, or support tooling. Those requirements are written, not
  demonstrated ([02-capability-catalog.md](02-capability-catalog.md),
  [03-user-journeys.md](03-user-journeys.md)).
- **Internal delivery documentation** of the demonstration fleet — its
  runtime, infrastructure, or internal design records. These describe how
  the reference build is built and hosted, not what a native build on
  Kibble & Co.'s store must do.
- **Production data or credentials of any kind.**

## 10.5 Standing caution

Where the demonstration fleet's behavior and the written acceptance criteria
diverge, the written criteria govern, and the divergence should be reported
(see
[08-scope-boundary-and-engagement-model.md](08-scope-boundary-and-engagement-model.md)).
The fleet retires ambiguity about intended behavior; it does not replace the
contract.

---

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.