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:
- 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); the demonstration is the fastest way to understand them.
- Feasibility signal, not feasibility proof. The MVP journeys this package describes (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.
- 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, 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). 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.