Subscription operations: build with merchants before fixing the rules

12 November 2026. This changes the implementation recommendation, not the breadth of the product vision. The studio is a set of hypotheses to discuss with merchants. It is not a validated operating model for a roastery.

Decision

Recruit at least one operational design partner before implementing advanced recurring allocation. A roaster running a curated club and a merchant running a customer-built recurring box should both participate; one merchant may cover both, but a second business tests whether the solution generalizes. Use three to five additional conversations to expose variations. These are proposed discovery targets, not completed interviews or a representative market sample.

Continue prototyping and building source-backed coffee data while discovery happens. Do not make a production promise about automatic capacity limits, recurring selection or stock protection until the merchant workflow and the exact provider behavior are tested together. A good configuration screen cannot establish the correct business rules.

Why “100 bags” does not determine subscription capacity

First establish what the number means: physically on hand, currently sellable, or a future merchant supply assumption. Shopify distinguishes available stock from committed, unavailable and incoming quantities. Starting from available stock means existing committed orders must not be deducted again. Shopify inventory states.

Illustrative planning example, one physical 250 g variant at one eligible location:

At two bags per first delivery, that suggests 15 additional first deliveries in this window. It does not support 15 indefinite subscriptions, reserve any stock, or protect against a simultaneous ordinary order. An actual admission limit needs an enforceable stock/allocation mechanism, a location and a time window. A forecast alone cannot supply that guarantee.

If 100 means 100 kg of unroasted coffee, this calculation does not apply. Coffee Kit does not convert green coffee into sellable bag quantities or schedule roasting. The merchant or an existing production system supplies the approved sellable quantities and expected availability. Several bag sizes or grinds sharing one physical pool require an explicit mapping; treating them as independent stock would overstate capacity.

Four distinct decisions

1. Accepting new customers: allow enrollment, limit the first shipment, offer a later start, or stop new enrollment for a particular offer. Do not pause existing subscribers by accident.
2. Planning existing deliveries: count due cycles, physical components, customer choices, skipped cycles and unresolved selections within a horizon. A club with no selected coffee has demand even though it lacks a SKU allocation.
3. Protecting stock: identify what mechanism actually prevents another channel from selling it. A proposed allocation record is not a Shopify reservation. Reconcile competing ordinary, POS, reward and subscription orders.
4. Resolving shortages: delay, skip, obtain replacement consent or escalate according to the actual customer promise. Confirm the provider applied the operation; a submitted request is not a stopped charge.

Shopify billing attempts can respect the product variant inventory policy or explicitly allow overselling. There is no separate universal “force no overselling” value in that enum; respecting the variant policy also respects a variant configured to keep selling. The app must inspect the configuration and verify the resulting order behavior. Billing inventory policy.

Shopify documents inventory-related billing failures when stock-tracked variants cannot oversell. Prepaid subscription inventory is not automatically reserved for the entire future term: its fulfillment-cycle behavior needs separate review. Neither fact proves that a selected third-party provider can offer a reliable pre-charge hold. Subscription contract billing, subscription fulfillment and reservations.

The two difficult models need different observations

A pooled total of 100 bags is insufficient if every box must contain one of two scarce coffees. Capacity is constrained by the required components, not just the sum of all coffees. A lower-stock decaf coffee cannot be replaced by a plentiful caffeinated coffee to make the numbers work.

Discovery sessions and evidence

Meet the person who actually prepares subscription orders, not only the owner buying software. Ask them to show the last normal cycle, a sold-out coffee, a late customer edit and a failed payment. Begin with their current process before presenting our studio.

Request only the minimal redacted artifacts needed: variant/location inventory export, upcoming cycle quantities and dates, anonymized contract IDs and component choices, an ordinary/POS order sequence, current app settings, customer terms, and the spreadsheet or notes used for allocation. Personal customer data is unnecessary for this first exercise.

Questions to answer together:

• Are subscriptions rolling from signup or grouped on calendar dates? When can customers change a box?
• Are quantities recorded as ready bags, finished bulk coffee or planned output? Which system owns each?
• Do whole-bean and ground variants share a stock pool? How are 250 g and 1 kg related?
• Which location can fulfill each order? Can stock transfer in time, or is that merely an assumption?
• Are subscribers prioritized over ordinary/POS buyers, and how is that priority enforced today?
• Does the merchant count unpaid retries as demand? When does a failed payment release an allocation?
• Does a tier promise a particular coffee, origin, category, rarity, bag count or price?
• How do late edits, cancellations, refunds, prepaid gifts and an incomplete box affect the next cycle?
• Who can authorize substitutes, a different price, a later date or a skip? What does the customer receive?
• Which alerts are actionable, how much warning is useful, and who handles them while the owner is away?

Deliver a one-page observed process, state/ownership map, inventory-unit map, timeline, exception list and the merchant's own definition of a successful cycle. Record differences between businesses instead of silently making one shop's habit the default for everyone.

Validation sequence

1. Historical replay: reconstruct at least one ordinary and one exception cycle from real redacted records. Account for every bag and identify precisely when demand becomes an order.
2. Shadow forecast: show recommendations alongside the merchant's process without changing stock, contracts or billing. Compare counts, timing, false alerts and missing exceptions.
3. Assisted operation: one merchant, one offer model, known component mapping and a named human approving actions. Log decisions and reconcile provider outcomes.
4. Narrow automation: automate only a repeatedly validated rule with explicit permission, idempotency, freshness checks and a recovery path. Test simultaneous purchases and provider timeouts before promising automatic stops.

A merchant interview alone does not validate lifecycle reliability; a technical sandbox alone does not validate the workflow. Both are needed. The proposed pilot should measure reconciliation errors, shortages caught before cutoff, time spent reviewing, alert usefulness, stock oversells and incorrect charges—not only whether the builder looks easy.

Impact on scope and cost

The initial cost allowance is not an estimate for this full planning/allocation system. Demand visibility, alerts, enforceable capacity, component allocation and provider controls are separate increments to estimate after discovery. Do not hide them inside “subscription builder.” The demand and inventory specification defines the proposed backend and visual layer, including loyalty demand. Roasting schedules, green-coffee purchasing and production logistics remain outside Coffee Kit.

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