Coffee Kit subscription reference atlas

12 November 2026. Six different product journeys, with a shared catalog and subscription workspace. This is the full product vision for the Subscription Studio, not a restriction to a refill MVP. The original UX report remains unchanged. This atlas adds the subscription breadth needed for Astra’s separate pages.

Evidence and design boundary

I opened 26 original supplied screenshots individually at original detail, including Wogan’s complete supplied sequence and Tanat’s intermediate screens. Contact sheets were not used as evidence for this atlas. The JSON manifest (local handoff artifact) records exact paths, observed controls, limitations and journey mappings. Eight merchants are represented in those images; Trade supplies additional official web evidence for recipient redemption.

Observed means visible in an original screenshot; it does not mean I operated that merchant’s interface. Documented means current official merchant copy inspected on the web. Proposed means Coffee Kit’s design. All backend rules below are inferred requirements for our proposed promise, not claims about competitors’ software. No payment, renewal, recipient redemption or merchant account was tested. No screenshots were edited, and no frontend/theme code was changed.

The references support different structures, not six branded versions of one wizard:

1. Fixed refill: keep buying a known coffee

Observed. Devoción’s original Honey PDP shows 12oz, 2lb and 5lb sizes, a grind selector, quantity, one-time versus subscription purchase, and a two-week interval. The subscription option is selected and its action says “Subscribe now.” A large packshot remains beside the compact controls. This is a known-product purchase, not a discovery quiz. The visible incentive copy is marketing, not independently measured savings or retention evidence. Source page shown in the image: Honey.

Coffee Kit translation. Keep this journey inside the PDP or quick-buy panel: existing coffee → bag/grind → recurring cadence → editable price summary. Show amount per delivery and the next charge separately. Returning shoppers should not answer taste questions to replenish their usual blend. For Astra, use the existing live quick-buy capture as the current foundation, then label the recurring controls as proposed. Admin setup needs eligible variants, cadence, pricing and sold-out behavior, with a matching PDP preview.

Backend rules. Store the physical variant, quantity, agreed recurring price and cadence. Catalog changes must not silently rewrite the promise. Define unavailable/discontinued behavior, payment recovery, skips and cancellation. A new lot sold under a new variant requires explicit handling even when the blend name stays familiar. Do not equate changing a selector with editing a subscription contract.

2. Curated club tiers: buy a selection standard

Observed. Nordic Brew Lab’s comparison separates Reserve (€48/month) from Rare + Exclusive (€78/month). The latter adds a rare coffee to the regular selection. Its product detail specifies two approximately 250g bags plus a 90–125g rare bag, monthly purchase and a prepay option. Visible copy distinguishes the initial dispatch from subsequent monthly cutoff scheduling. These are captured offers and stated policies, not verified fulfillment. Source page.

Coffee Kit translation. Give clubs their own comparison page: “Everyday discoveries,” “Seasonal selection,” and “Rare releases” are example merchant-editable labels. Each tier explains number/weight of bags, selection standard, price, first shipment and subsequent schedule. Its detail page shows this cycle’s coffees and an archive of earlier selections. Merchant setup has tier composition, eligible lots and a cycle calendar. “Prepare next selection” opens the actual physical coffees, required quantities and affected subscribers for review.

Backend rules. Keep club identity separate from each cycle’s physical contents. Freeze a versioned selection before billing; validate every size/grind mapping, stock requirement and agreed price. Different component weights need explicit allocation. Manage membership cutoffs independently from first-order shipping. One-time extras must not recur accidentally. Prepay is a separate commercial mode, not a cosmetic checkbox. These rules apply whether Coffee Kit owns the engine or uses a verified integration.

3. Customer-built box: choose multiple specific coffees

Observed, with strong intermediate evidence. Wogan first offers a monthly special, known-coffee selection and guided help. The known-coffee branch is selected. Then come recipient, brew method, and a 16-product grid with “02 coffees selected”. The amount step asks how much of each coffee, offering 250g/500g/1kg. The review names Nicaragua Finca La Bastilla and Kenya Kariti Kianjege AA, commercial espresso, 2 × 1kg and every three weeks. The cart displays two separate recurring lines. Source builder.

This proves a customer-composed multi-coffee purchase. It does not prove a fixed-price “choose any three” bundle, one atomic recurring box, or a monthly reselection portal.

Coffee Kit translation. Build a dedicated catalog workspace with coffee facts, taste filters, quantity controls and a persistent selection tray. Preserve selections while changing grind or opening coffee details. Merchant setup explicitly chooses a pricing model: sum of selected coffees, or a configured box allowance with disclosed premiums. Show “2 coffees / 1kg each / 2kg total,” avoiding ambiguous bag-count copy. The next-delivery page should support reviewing or changing the composition before a disclosed deadline; that is proposed functionality beyond these screenshots.

Backend rules. Store component variants and quantities, compatible cadence, selection limits and pricing rules. Define whether selections repeat, expire or reopen each cycle. Handle non-response, unavailable components, partially valid boxes, substitutions, discounts and shipping. Specify whether one failed component holds the whole delivery. Several recurring cart lines do not establish synchronized renewals; box-level promises require that behavior to be proven.

4. Personalized guided club: configure preferences, then explain the match

Observed. Tanat’s brew question uses filter/espresso photography. The grind step distinguishes preparation methods from whole bean. The amount step offers 200g, 2×200g and 4×200g; the latter describes two origins twice, not four distinct coffees. A quality choice distinguishes Classic from Micro-lots 88+. The summary resolves to a micro-lot, filter-ground 2×200g subscription every four weeks. Source page.

This is guided club configuration. No taste-scoring algorithm, named-coffee multiselect or adaptive recommendation loop is visible. WatchHouse’s brew step provides a second visual treatment: large editorial imagery with a narrow question panel. Its next product step presents named alternatives, not a multi-item box.

Coffee Kit translation. Use preparation, whole-bean/grind, taste preference, adventurousness and consumption only where they affect the offer. Finish with an explained match, first contents and editable answers. Let knowledgeable shoppers jump directly to clubs. Merchant setup connects answers to explicit eligibility rules; preview explains why a coffee qualifies. Ongoing taste feedback and future selection adjustment belong in the full vision, visibly marked as additional capability.

Backend rules. Persist answers separately from order merchandise. Version recommendation rules, respect hard exclusions and define fallback behavior when no eligible lot exists. A preference is not permission for arbitrary substitutions or price increases. Maintain selection history if promising variety, and distinguish an initial recommendation from ongoing personalized rotation.

5. Prepaid gift: separate the payer from the recipient

Observed boundary. Sey’s original form visibly includes a prepaid-gift checkbox beneath package quantities. It is unchecked; recipient, duration and activation screens are absent. Passenger’s audience tabs include gifting, but “For me” is selected. Neither image establishes a complete gift journey.

Documented supplement. Trade’s official gift page, inspected today, describes a single charge with no automatic renewal, selectable duration, email or printable delivery, recipient details and a scheduled notification. Its FAQ places gift-code activation, account creation, quiz and shipping details with the recipient. This is inspected web text, not a viewed Trade screenshot or completed redemption test.

Coffee Kit translation. Astra needs two linked experiences: a payer page with duration/delivery count, total prepaid price, message and notification preview; then a recipient activation page with remaining entitlement, coffee preferences, address and first-shipment choice. Clearly distinguish the gift-message date from the coffee dispatch date. The recipient’s home screen shows deliveries remaining and a voluntary continuation offer after expiry. Merchant setup defines available terms, redemption rules and support actions.

Backend rules. Model payer, recipient, purchase, activation token and finite fulfillment entitlement separately. Redemptions must be single-use and recoverable through controlled support. Define unclaimed gifts, delayed activation, paused shipments, partial refunds, delivery failures and who receives each notification. Track remaining deliveries independently from calendar months. Expiry must not become an undisclosed charge to either person. An ordinary gift card or finite pay-per-delivery contract is not equivalent to this promise.

6. Office bulk: manage consumption and continuity

Observed. Assembly’s office espresso page shows 4kg, whole bean, a two-week cadence and quantity. Visible copy offers 4/6/8kg every 2/4/6 weeks and says amount/schedule can change through a portal. The portal itself is not shown. Source product. Passenger’s audience tabs reinforce that office purchasing is a distinct context without requiring a separate brand.

Coffee Kit translation. Use a compact supply planner: headcount or known kilograms, brew method, consumption estimate, package size and delivery cadence. Show assumptions and let the buyer override recommendations. Summary: kilograms per delivery, estimated coverage, destination and next shipment. Include office-closure skips and an administrator handover in the full vision. Bulk purchasing should not force a lifestyle quiz. Merchant setup defines bulk variants, quantity bands, available frequencies and supported destinations.

Backend rules. Convert consumption into sellable pack quantities without promising false precision. Preserve bulk pricing, stock and shipping constraints. Define change cutoffs and closures. Separate office recipient/contact from payer and authorized account manager. Multiple locations, purchase orders, invoice terms and B2B pricing are additional explicit capabilities; no supplied image proves them. They can extend this model after commercial/platform validation, rather than being silently implied by the word “office.”

Astra composition and shared operating workflow

Build six distinct Studio detail pages with merchant rules, shopper preview and next-delivery behavior. Connect them to one catalog, one offer registry and one exception queue. A merchant should move from reviewed coffee data to an offer, publish its shopping experience, and prepare future deliveries without reconstructing configuration across overlays. Assisted switching can map and review an existing setup; it does not establish permission or technical ability to transfer contracts automatically.

Use current Polaris App Home web components for admin; the parent owns component verification. Keep Coffeetale styling inside shopper previews. Preserve the established palette: surface #f8f8f5, ink #2a1b17, square cards #F0F1EC, borders #e7e7e7, action #b83910, stone #e9e2d9; DM Sans/Manrope with restrained Fraunces italic and monospace metadata. Exact setting provenance and real asset links remain in the website handoff.

Use real collection, coffee PDP and quiz result captures for the current foundation. The external merchant images are reference evidence, not Coffee Kit product screenshots. New box, gift and office screens must be labeled concepts in current Coffeetale style. Do not substitute the same supplied Figma wizard for all six models.

The existing theme supplies coffee presentation, variant selection and discovery; it does not establish these subscription backends. The subscription architecture study retains the platform/provider constraints. Implementation may proceed in phases, but keep all six models in the product architecture and demonstrate their distinct rules. Each release claim requires an end-to-end test of enrollment, renewal, inventory, customer changes and exception recovery for that specific model.

Source: subscription-reference-atlas.md The complete Markdown handoff and private datasets remain in the local project. This web edition includes selected supporting visuals and scenario downloads.