Coffee Kit: product decisions, implementation handoff and prototype specification

12 November 2026. Strategy and design specification; no app implementation, merchant changes, outreach or live subscription tests were performed. This document supports the integrated business and product plan. Its architecture decisions are conditional on the explicit tests below, not claims of working integrations.

1. Product decision and scope

Full-vision extension: the full product blueprint, Subscription Studio specification, reference atlas and loyalty specification are authoritative for the expanded presentation. All six subscription models and loyalty need concrete demonstrations. The initial implementation boundaries below remain a delivery sequence, not a limit on the product concept or a reason to hide advanced models from the pitch.

Build toward the preferred solution for selling coffee on Shopify. The first experiment must demonstrate a connected workflow: source-backed coffee facts → consistent cards and product pages → guided purchase → correct next coffee when a lot changes. Existing subscription usage is a benchmark to beat and a potential switching opportunity. It does not confine Coffee Kit to a permanent overlay.

Test $99/store/month without a Coffee Kit percentage of sales for the connected offer. This is a proposed price, not demonstrated willingness to pay. Display provider and email charges alongside it. Do not sell automatic rotation when only enrollment works, and do not retain the same value claim if provider access removes the operational benefit.

The architecture decision is a provider-independent coffee model, explicit physical variants, and a bounded comparison of Seal integration with a narrow owned engine. Seal is the first integration candidate because its published API entitlement includes every tier, including Free; Appstle's approved partner route is the second candidate. Neither has passed a Coffee Kit integration test. An owned engine becomes the preferred route if it wins paid merchant preference and provides reliable pre-charge selection more economically than provider orchestration. Its scope and operating responsibilities must be budgeted explicitly.

Delivery labels

V1 target

• Reviewed import from existing Shopify products, bag photos, PDF/text and a constrained CSV format; preserve source evidence and field ownership.
• A shared Coffee Card, scoped coffee grid, PDP facts and option controls. One catalog feeds each placement. A small deterministic finder uses approved descriptors; no invented numerical taste scores.
• Same-coffee subscription enrollment using actual eligible variants and selling plans; one supported provider initially if the provider route wins.
• A proposed roaster's-choice flow with one actual coffee variant and quantity per cycle, merchant review, explicit customer promise, price checks and verified stock/order behavior. Release only after the lifecycle gate.
• Shared styles, preview, explicit draft/published states, supported placement, export and connection health.
• One verified retention handoff if capacity permits. Existing services own marketing delivery and rewards; transactional subscription notices are mandatory for an owned engine.

Future: multi-coffee recurring boxes, prepaid gifts, arbitrary monthly customer selections, custom roast cutoffs, a loyalty engine, marketing email platform, broad agency write APIs, universal native-grid replacement, POS enrollment, pickup scheduling, multi-platform commerce and roasting logistics. Existing theme brew-guide designs may be reused as content after the core workflow passes, but are not another launch workstream.

2. Three subscription routes and reversal conditions

The initial two-week architecture gate compares the same fixed-SKU and one-physical-lot club scenarios. A superficial enrollment demo cannot decide the deep-integration versus engine question. Evaluate total cost as engineering + maintenance + merchant fees + support + incident coverage + migration effort. Compare measured effort; do not assume an API adapter is cheaper than an owned engine.

Choose deep integration if Seal or an approved Appstle route provides the required lifecycle, predictable commercial access and acceptable total cost. Choose an owned-engine pilot if the provider cannot prevent charging stale selections, lacks effective writes, requires unaffordable access, or merchants demonstrably prefer/pay for unified management, and the owned lifecycle passes the same tests. Choose purchase-only only for buyers who explicitly value that narrower product at a newly tested price. Stop the subscription-led launch if neither operational route passes. Continue design/catalog validation without marketing unproved renewal automation.

Shopify supplies checkout, vaulting and subscription APIs; app-side scheduling, recovery and management remain real responsibilities. Contract ownership scopes are not permission to edit another provider's contracts. See responsibility model and contract reference.

Correct the bundle assumption

Shopify's 2026-10 calculation API supports bundle contract editing. This does not prove every initial checkout or provider supports recurring bundles. Separate initial selling-plan checkout, contract representation, provider adoption and subsequent fulfillment. The earlier blanket statement that Cart Transform restrictions make all subscription bundles impossible is superseded. Keep mixed boxes out of v1 for scope and verification reasons. Bundle contract editing, merchant bundle restrictions, full evidence reconciliation.

Narrow owned-engine boundary

One verified domestic shipping market/currency and gateway; pay-per-delivery; a small set of supported cadences; same-coffee refill and one physical coffee per club cycle; fixed disclosed club price; pause, skip, cancel, address/payment-method update and exception handling. New customers/clubs first. Existing contract migration is a separate verified service.

Audit Shopify's reference app rather than rebuilding its scaffolding from scratch. The evidence report found recurring billing/recovery patterns but also email services that return success without sending, unstable webhook configuration and legacy draft editing. Budget production queues and secured job endpoints, actual transactional email delivery, pinned versions and 2026-10 calculation adaptation. Passing a local scaffold is not release readiness. Reference app, core system responsibilities, pinned source audit.

3. Information architecture

Use six product destinations, including first-class Loyalty. Settings is a utility destination. Keep merchant language visible; implementation details belong in diagnostics and documentation.

Experiences owns presentation and placement. Subscriptions owns the commercial model and renewal rules. An Experience refers to a named subscription configuration; it does not copy it. Settings owns a shared style profile; an experience may choose an approved profile and documented local layout overrides. Theme Editor owns placement. Shopify remains authoritative for commercial products, variants and inventory; the subscription engine remains authoritative for contracts.

4. Prototype handoff: exact deliverables and runtime boundaries

The user's final deliverable set is exactly three: merchant-facing product site at /demo; internal business plan and interactive wireframes at /internal; local Markdown documents containing the complete study and development handoff. The user will push to GitHub Pages at coffee-kit.krownthemes.com. No Sites registration or publishing is part of this handoff. The website agent owns static site/dist/demo, internal entry/wireframe pages and shared assets; the parent owns the readable report/evidence rendering. This document does not implement either site.

The marketing page presents the full product ambition through the next-coffee story. Use an honest concept/early-access label and a proposed $99 price. Distinguish initial enrollment from proposed rotation. Provider logos, if used, are researched candidates until integrations pass; do not imply partnership. Avoid invented customers, reviews, conversion uplift, working signup submission or market leadership claims.

The internal app wireframes must use actual current Polaris Web Components. Use https://cdn.shopify.com/shopifycloud/polaris-2.0.js pinned to 2.0, or the explicitly versioned polaris-2.js; unversioned polaris.js remains legacy 1.x. This is a standalone Polaris prototype, not authenticated App Bridge or a real embedded app. Do not add fake API keys, auth or checkout. Parent reports browser verification of actual s-page, s-button and s-text-field registration/rendering without App Bridge. The website builder must independently check its finished screens. Current App Home components, Polaris 2.0 announcement.

Storefront mockups must use the supplied actual Coffeetale/Figma screenshots and existing visual vocabulary. Identify screenshots as design references, not functioning embedded UI. Missing interactive mockups should follow Coffeetale's card, option-selector and typography treatment. Admin remains Polaris. Detailed source provenance belongs in the UX asset report.

Shared demo dataset

Use fictional store Example Roastery and a persistent “Interactive concept · demo data” indicator. Synthetic values below test behavior; they are not source facts or a proposed real merchant offer.

Demo variants include 250g/1kg and whole bean/filter where explicitly populated. A missing espresso-ground option must stay unavailable. “Two bags” means quantity two of one variant in v1, not a mixed box. Stock is an observed demo value, not a reservation. Seed a refill subscription and a roaster's-choice subscription so permission differences can be exercised.

Keep changes in browser memory or clearly named local prototype storage. Reset demo restores all fixtures. A local preview action changes only the prototype. No network write, real document upload, subscription charge, email, account connection or collected lead is needed. The source screen can select a seeded sample sheet and show its corresponding excerpt.

Flow A: dashboard → coffee source → review → preview

1. Dashboard shows “1 coffee needs review” and “1 upcoming shipment needs attention.” These link to the same underlying demo records as the other screens; avoid unconnected showcase cards.
2. Coffees offers Improve existing coffee and Create draft coffee. Selecting existing Sierra Lot B retains its Shopify identity. Sample source selection opens a source pane with page/excerpt and proposed facts.
3. Review uses three regions: source evidence; field/value/status controls; resulting coffee preview. Statuses are Observed, Normalized, Suggested, Unknown and Conflict. Changing process cannot silently overwrite a merchant's later edit. Unsupported altitude stays blank; tasting notes do not create numerical chart scores.
4. Each field can be accepted, corrected or omitted. Required commercial fields—product/variant mapping, price and publication decision—are reviewed separately from descriptive extraction. If no real variant is mapped, purchase preview shows an actionable explanation.
5. Preview approved changes opens tabs for Card, Product page, Finder and Builder. Edit a tasting note and show the same change everywhere. Display an impact summary: affected placements and subscriptions requiring review. Catalog publication does not itself change a contract.
6. Save demo draft records the review state. Publish in demo explicitly simulates publication and adds an audit item. In the real app these are authenticated, idempotent writes followed by read-back verification.

Flow B: experiences → style library → shared card preview

The experience list contains Coffee collection, Product facts, Coffee finder and Subscription page. Each row shows Draft/Live-in-demo, placement and chosen shared style. Opening the style library shows three named, authored treatments grounded in Coffeetale: Essential, Origin story, Taste detail. These are proposed preset labels, not claims of existing named theme presets.

Every treatment previews the same coffee and purchase state. Controls cover density, image treatment, visible approved facts, token-based typography/colors, corner treatment and summary detail. The preview switches between a collection card, finder result and builder coffee choice. Changes to a shared style show “Used in 3 experiences” with affected previews before applying. Local overrides are limited and visibly named. Never maintain two silent editors for the same setting.

Show wide and narrow widths. Empty fields disappear cleanly. Out-of-stock and missing-option states remain legible. An external-theme preview demonstrates a standalone Coffee Kit grid; it does not pretend to replace every native collection/search card. The native Coffeetale preview may use shared assets only after its capability/version contract is verified.

Flow C: merchant subscription builder

Use a persistent step list on the left, working form in the center, and live customer summary on the right. At narrow widths, step navigation becomes a compact progress control and preview opens as a labeled panel. Save draft is available throughout; completion is based on meaningful validation rather than merely visiting steps.

In a purchase-only configuration, step 5 explains “Renewal changes are managed in your subscription provider” and offers a useful provider-management link. It must not show an operable automatic rotation toggle. The proposed deep workflow remains separately explorable in the internal prototype, labeled as such.

Flow D: customer enrollment

Entry points are the shared coffee card, PDP and named subscription page. The same selection model supports a compact inline form and a guided flow; do not implement two contradictory pricing systems.

Guided sequence: Choose your coffee or club → Size and grind → Bags per delivery → Delivery frequency → Review. Brew method is an optional helper that filters eligible grinds/coffees, not an obligatory quiz before buying. Returning customers can use the compact form. A customer who knows the desired coffee can skip discovery.

The review shows first coffee, exact physical variant, quantity, recurring amount, supported cadence, first-charge/first-shipment distinction, shipping/tax treatment, cancellation/management route and relevant replacement terms. Use “Continue to checkout” in production; the prototype says “Preview checkout summary.” It ends in a demo summary, never a payment form.

For Same coffee, use illustrative copy: “Receive this coffee each delivery. If it becomes unavailable, we will ask you to choose an alternative or manage the next delivery.” For Roaster's choice, use: “The roaster chooses a coffee each cycle within this club's stated category. Your selected size, grind and agreed price remain fixed.” These are proposed UX copy, not legal terms or proof of consent adequacy. Price/category changes outside those terms return to review and any required customer authorization.

Flow E: next-shipment review and permission

Subscriptions opens an upcoming-shipments table with cutoff, current physical coffee, proposed coffee, size/grind, price, stock check and action state. Select the Sierra Lot A exception: six bags needed, two currently available. The detail shows the old/new coffee side by side and the actual variant mapping.

• Same-coffee record: Sierra Lot B may be suggested but cannot become Applied merely because the merchant likes its profile. State is Customer action required until the applicable approval is recorded. A demo action can simulate the customer's choice explicitly and label it simulated.
• Roaster's-choice record: compatible Sierra Lot B at the agreed $16 can be merchant-approved within the disclosed club rules. Show eligibility reasons, stock freshness and confirmation state. Changing to $18 Highland Lot C triggers Price review; selecting caffeinated coffee for Evening Decaf fails eligibility.
• Stale stock: changing the fixture to insufficient stock invalidates the old approval and requires a fresh decision. Do not promise stock is reserved merely because a preview passed.
• Provider timeout: show Pending confirmation, not Applied. A retry first reconciles the operation; it must not blindly repeat a write or charge.
• Cutoff reached: show confirmed skip/hold only if the selected engine actually confirms it. Otherwise show an urgent unresolved exception and provider-management route. Never claim Coffee Kit prevented billing without a tested barrier.

The final step shows old/new amounts, discount/delivery differences, eligibility, stock timestamp, consent basis, effective cycle and resulting status. In a real implementation, committing a contract update and successfully billing it are separate events. Historical orders retain the original coffee identity.

Flow F: retention & integrations

Show a useful operational screen: subscription engine connection, last successful sync, supported capabilities, customer portal link and an example approved-coffee event/template. Status vocabulary: Connected and verified / Needs attention / Demo connection / Not connected. Do not use generic green checks for simulated integrations.

Include a sample “New suitable coffee” email preview fed by approved product facts, with a handoff destination and consent/eligibility explanation. The prototype displays and copies the example; it does not send. In v1, only one tested event/template handoff is promised. Marketing tools own audience permission, unsubscribe handling and sending; an owned subscription engine separately needs reliable transactional notices. Loyalty and pickup remain provider links or future prose, not blank modules.

Flow G: agency plain rendering

Provide an internal demonstration with Designed and Plain tabs. Both render the same approved coffee object and purchase choices. Plain uses semantic text, form labels and product links with minimal styling; removing Coffee Kit styling must not remove meaning or change price/eligibility.

An adjacent developer panel shows a small fictional versioned payload, mapping public coffee fields to output and a read-only example. Clearly label API examples as proposed contracts. No browser-visible provider key, customer data or contract-write token. V1 agency support is merchant-owned Shopify fields, documented read semantics and one CSS-free renderer; a general public configuration/write API is future scope.

5. Developer handoff

Work package boundaries

Source of truth and minimum records

Shopify Product owns its commercial identity; Variant owns sellable size/grind, price and inventory link. CoffeeLot owns origin/producer/process/harvest/source descriptors and stable identity. RoastOffering associates lot and product; a blend can reference multiple origins without pretending to be one farm. SensoryAssessment contains source, scale and actual measured values; absent measurements remain absent. SourceEvidence stores file/page/excerpt and extraction state. FieldMapping records source/target types, precedence and last-seen digest. ExperienceConfig references approved catalog filters and style/version. SubscriptionProgram stores the customer promise, eligibility and supported cadence. CycleSelection records the intended physical variant, agreement/approval, effective cycle and engine confirmation. ContractMirror is explicitly a cached engine view, never authority by itself.

Merchant-owned public coffee definitions should be adopted where compatible or created through GraphQL in non-reserved namespaces/types. Granting merchant access to app-owned data does not change its lifecycle. Keep private supplier files, customer preferences, credentials and operational logs outside public coffee facts. Review schema collisions before selecting a namespace. Export reviewed facts and mappings. Metafield definitions, metaobject lifecycle, detailed data handoff.

Import state and write safety

Source received → extracted → validation/review required → approved draft → publish pending → read-back verified. Failure retains the last good published version. A source document is untrusted input, never operational instructions. Normalize units deterministically and preserve original text. Price, inventory, SKU construction and publication require explicit merchant decisions. Use source hashes for duplicate detection and an operation ID for retries. Re-read edited fields before patching; if another actor changed them, show a conflict. Undo checks the current digest before restoring a previous value.

Use a multimodal provider adapter and evaluate current low-cost models on the same gold set. The evidence note compares advertised Haiku 5.5 and Gemini 3.5 Flash-Lite costs; no accuracy benchmark was run. Budget image/PDF processing, retries, storage and review time, not tokens alone. Proposed test set: 100 sources with at least 30 held out; measure grounded-field precision, omissions, incorrect units and review minutes. Zero fabricated critical commercial facts is a release requirement, not a claim that a small holdout proves universal safety.

Subscription invariants

1. The actual physical variant on the resulting order matches the approved coffee, size and grind. A club label or descriptive line property is not inventory allocation.
2. Enrollment eligibility is checked against the resolved variant and selling plan. Existing contract terms do not silently follow catalog or plan edits.
3. A specific-coffee agreement is not blanket replacement permission. Roaster's-choice permission is bounded by disclosed category/price/quantity terms.
4. Preview stock is timestamped; the engine's actual order/inventory policy governs consumption. Coffee Kit never double-decrements inventory to imitate reservation.
5. Each cycle has a stable identity. Duplicate jobs/webhooks must not create duplicate charges, changes or notices. Unknown outcomes trigger reconciliation before retry.
6. Customer cancellation/skip and merchant selection changes may race. Re-read contract status/revision before mutation and again before an owned-engine billing attempt. The provider route must establish an equivalent supported barrier.
7. Changing a contract is not a charge; a successful charge is not proof of correct fulfillment. Reconcile contract, billing attempt, resulting order and physical line.
8. Existing historical lot identity and order data remain intact. Do not rename one merchandise SKU every cycle to hide changing stock.

For 2026-10 calculation edits, a supplied lines array replaces the existing list: rebuild from fresh state and include every retained line fully. Calculate, inspect errors/projected totals, commit and confirm. Do not transplant a single-line patch assumption from older APIs. Calculation migration guide.

Release tests for either operational route

Theme and agency boundary

Start with current Coffeetale plus one selected external theme/version. Local is a candidate based on actual buyer fit and adapter cost, not a promised third compatibility commitment. A theme name alone does not establish the expected capabilities. Define token mapping, cart submission, drawer refresh and section-rendering contracts. A generic correct cart-page fallback is preferable to claiming every host drawer works.

Render approved facts in initial HTML where feasible; interactive controls progressively enhance them. Coordinate existing Product/Offer structured data rather than emit contradictory duplicate entities. This supports understandable product information; it does not guarantee SEO rankings or AI recommendations. Google product guidance, AI search guidance.

Measure disabled/minimal/full features on mobile with cold/warm cache: asset transfer, main-thread work, layout shift, core page usability and add-to-cart latency. Extract renderer dependencies from Hydra; do not copy an entire theme runtime into the app. Persistent merchant facts do not guarantee persistent app-hosted UI after uninstall. Agency presentation uses approved public data; contract actions stay authenticated server-side.

6. Designer handoff

Design one coherent merchant workflow and a reusable storefront family. Do not create separate visual systems for cards, finder results and builder choices. Use actual Coffeetale references; reconcile labels, typography, options and spacing before adding new treatments. The admin uses current Polaris patterns and component semantics.

Deliver an annotated route map; shared field/status vocabulary; all seven prototype flows above; wide/narrow layouts; keyboard/focus behavior; source-review conflict states; purchase and renewal summaries; and a component/state inventory. Each screen annotation states source of truth, what is draft versus published, who can change it, and what action affects customers.

Required states: initial empty, loading, partial import, low-confidence fact, missing field, conflicting edit, no eligible coffee, unavailable variant, stale stock, provider disconnected, permission missing, price change, pending confirmation, confirmed success and recoverable failure. Error messages name the affected object and next action. A toast alone is inadequate for unresolved shipment exceptions.

Use text labels with sensory colors and icons. Charts need textual alternatives and an explicit source/scale. Taste is not an ingredient/allergen claim. Keep keyboard focus predictable across step changes; announce changes in price/eligibility without constant interruption. Sticky summaries must not obscure content on narrow screens. Back navigation retains choices. Avoid a full-page wizard where the experienced merchant needs one field edit.

Test three merchant tasks: approve an incomplete source, configure a refill without guidance, and resolve a sold-out lot with different subscription permissions. Test three shopper tasks: buy a known coffee quickly, find a suitable coffee without a taste chart, and explain what will arrive and cost next month. Record completion, mistakes and assistance; preference for a beautiful mockup is not proof of conversion uplift.

7. Switching and migration handoff

The product must improve a merchant's complete before/after workflow and bill. Prepare an assessment with actual invoices and tasks: catalog setup, new-lot maintenance, discovery configuration, subscriptions, customer portal, email, theme support and agency work. Identify what is genuinely removed and what remains. A provider fee retained after installing Coffee Kit is not a saving. A merchant already satisfied with a low-cost incumbent must gain enough measured value to justify switching.

Contract exports and payment-method authority are different. Do not assume a CSV transfers vault tokens or that product/order access transfers contracts. Confirm source and destination support, gateway constraints, allowed payment-method access, customer requirements and ownership of each active contract. Do not uninstall the old provider merely because new records imported. Shopify payment-method migration, contract ownership.

Migration sequence: inventory → classify unsupported cases → price service → obtain approved mapping and cutover plan → rehearse representative cases → schedule a controlled cutover → ensure only one scheduler owns each due cycle → reconcile amounts, dates, lines, status and payment references → observe first renewals → retire old services only when safe. Keep a per-contract migration ledger and exception queue. Before charging, rollback may restore an unchanged source state if supported; after money/order creation, use a separate corrective process, not a blind reverse import.

AI can draft mappings, compare exports, prepare checklists and summarize anomalies. A salesperson/support person can qualify the move and coordinate it. Humans retain approval of commercial promises; the developer owns payment/contract authority and cutover. A three-person team cannot absorb unlimited bespoke migrations in $99/month. Measure hours; charge scoped setup separately or use trained partners for nonstandard work. No migration or outreach is authorized or performed by this research.

8. Twelve-week execution plan

This is a full-time sequencing illustration, assuming 40 app-engineering hours/week for one developer, alongside one designer and one support/growth operator, with founder product decisions assigned explicitly. It is not a delivery forecast or fixed public launch date. The integrated plan's capacity scenario allows 32–48 spike hours plus 280–440 subsequent development hours: 312–488 developer hours before an owned engine or complex migration. At 25 app hours/week while protecting theme work, that means approximately 13–20 engineering weeks, before external approvals and scheduling delays. The nominal week numbers below therefore stretch when only 25 hours are available; early research/prototype milestones can proceed while production work remains incomplete. Start the clock when capacity and development access are available; holidays, app review and provider approval can further extend elapsed time.

Illustrative allocation within 60 nominal eight-hour developer days (480 hours at full-time app availability): 8 architecture/access, 12 catalog/review, 10 storefront/configuration, 12 provider lifecycle/integration work, 8 production/pilot readiness, 10 contingency. This is a rough work breakdown, not an additional estimate to add to the integrated plan's 312–488 hours. Replace both with the measured spike and backlog. It does not include a production owned engine within the same allowance. The subscription report's separate 240-hour owned-engine sensitivity adds roughly ten engineering weeks at 25 hours/week, subject to actual reuse and overlap; that sensitivity is not a measured estimate either. If ownership is selected, re-estimate and extend the calendar, or explicitly remove optional finder/retention expansion and reduce adapter scope for the engineering pilot. Do not hide extra engine work inside the same date and feature list. The full commercial proposition is revalidated whenever scope changes.

The designer leads flow quality and storefront system; developer owns architecture, correctness and incidents; support/growth owns merchant evidence, qualification, onboarding and issue taxonomy. Ruben/product owner chooses scope and go/no-go gates. A dedicated salesperson is optional after a repeatable offer exists; sales work is budgeted even if done by an existing role or AI-assisted. Protect existing theme obligations explicitly rather than treating three people as three full-time app hires.

9. Business gates relevant to development

Five qualified merchants accepting the actual price/scope, four useful launches, four second catalog/club actions and three paid renewals are proposed directional pilot gates from economics and validation, not universal statistical benchmarks. Include at least two paid merchants outside the existing Krown relationship before claiming independent distribution. A twelve-week window may not include enough natural renewals; extend observation rather than manufacture retention evidence.

At $99, $5 monthly hosting/AI allocation and 30 minutes support at $30/hour, contribution is $76.13 with 2.9% processing, or $61.28 with a simple additive 17.9% fee scenario. The latter needs 245 stores for $15,000 otherwise-unallocated fixed costs. Shopify's eligible first $1M lifetime app revenue since January 2025 has 0% revenue share, then 15%, plus 2.9% processing; associated developer accounts aggregate and theme revenue is excluded. Taxes/regional adjustments remain outside these scenarios. Confirm Krown's actual eligibility/threshold position. Official fee schedule.

At 500 stores, 30 minutes recurring support means 250 hours/month before onboarding or incidents. Use measured support as a scope constraint. Migration assistance has its own budget: two hours adds $60 at the illustrative rate; complex contract migration may cost substantially more. Do not count the same salaried support cost in both contribution and fixed-cost budgets. The original 15-row CSV's 5% reserve is a validated calculation scenario, not the actual mature fee schedule.

The verified market screen contains 5,820 strong-coffee/roaster identities and 1,073 with recent product creation plus a detected subscription app; the specialty intersection is 634. These indicate where to investigate recurring work, not confirmed buyer demand. The 5,990 broader roaster-language cohort includes weaker signals. At 842 paying stores and $99, gross ARR exceeds $1M, but this would require roughly 14.1% of the broad 5,990 screen or 32.3% of 2,606 specialty signals before disqualification. No feasible penetration forecast follows. Final market evidence, verified aggregates (local handoff artifact).

10. Evidence status and remaining questions

The platform/provider statements in this draft derive from subscriptions evidence; data/ownership from data and discovery; market counts from market evidence; economics from economics validation. Final visual/source references and competitive observations are documented in UX assets and competition/growth. Vendor claims do not establish quality, active paid use, dissatisfaction or merchant willingness to switch.

Open implementation questions: Which provider can demonstrably coordinate selection and charge timing? What price and access contract applies to Coffee Kit? Can a narrow owned engine pass the same matrix within measured capacity? Which merchant workflows justify switching? Which existing fields/theme versions can be adopted? How much source review and support is required on a second change? Which migration routes can preserve authorized payment methods and prevent duplicate renewal? Which retention handoff is worth its maintenance cost?

No question above prevents designing a concrete prototype. Each does constrain what may be marketed as implemented. The separate website should show the complete ambition, honest current status, and coherent simulated flows. Its launch or publication is not part of this strategy task.

Updated operational and discoverability scope

The complete concept now includes a first-class Demand & stock workspace, physical reward exposure, upcoming subscription demand and internal operational alerts. Advanced club/box rules must be developed with real merchants before automation. See operations discovery, demand/inventory backend and UI specification, and coffee data/AI discoverability. These increments are not absorbed into the earlier initial-release allowance. Merchant copy leads with the complete Shopify coffee-selling product and concrete capabilities.

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