Internal review · 12 November 2026
Coffee Kit: decisions, challenges and unanswered questions
12 November 2026. Read with the full product blueprint and main plan. The full vision includes six distinct subscription models and first-class loyalty. Implementation gates sequence that vision; they do not reduce the product to the initial pilot. The accompanying websites are interactive static demonstrations.
Decisions made for the proposal
| Decision | Why | Revisit when |
|---|---|---|
| Build toward a complete coffee-selling workflow | Data, presentation and recurring coffee changes share facts and rules | The repeated merchant task fails to justify a recurring fee |
| Target online coffee sellers first | Bean catalogs and subscriptions fit the proposed workflow | Evidence supports a separate café/POS segment |
| Test $99 per store, no revenue share initially | Predictable offer and measurable value comparison | Realized support, usage and willingness-to-pay evidence exists |
| Keep facts merchant-owned and exportable | Durable utility and agency compatibility | Only for genuinely private operational data, never to create artificial lock-in |
| Use actual physical variants as stock truth | A club label alone does not allocate physical coffee | A proven component/allocation design justifies extra complexity |
| Compare affordable integration with a narrow owned engine | Merchant economics and operational ownership both matter | Actual lifecycle tests and paid switching preference choose the route |
| Test Seal first; investigate Appstle partner access | API evidence and observed merchant prevalence | Entitlement, synchronization or commercial terms fail the promise |
| Use Coffeetale plus one tested external theme | Preserve distribution advantage and test independent value | Actual lost deals justify the next adapter |
| Use real current Polaris in admin | Shopify-native controls and a credible handoff | Current platform guidance changes |
| Develop advanced club/box operations with actual merchant partners | Inventory units, selection cutoffs and exception policies cannot be validated from screenshots | Historical replay and shadow cycles reconcile with real operations |
| Treat demand and stock visibility as a product area | Subscriptions and physical loyalty rewards share stock | A narrower view demonstrably covers the merchant's decisions |
| Make coffee data and AI discoverability explicit in the pitch | The app maintains a catalog across selling surfaces, not only a bag scanner | Actual quality/maintenance and channel diagnostics establish the value |
| Match Coffeetale for customer experiences | Reuse the team's existing visual/product work | Merchant branding needs a supported style adaptation |
| Make loyalty a first-class coffee experience; choose its delivery route separately | Customers need one clear earn/redeem experience; provider APIs, UI and pricing differ | Compare provider UI, paid API integration and a narrowly owned ledger against the proposed program |
| Use existing email and pickup services where their capabilities fit | Concentrate engineering on coffee-specific workflow | A narrowly measured gap merits ownership |
Deliver static /demo and /internal websites |
User will deploy to GitHub Pages | A separate production app implementation is commissioned |
Priority questions and cheapest useful tests
| Priority / owner | Question | What research established | Next evidence and pass condition |
|---|---|---|---|
| P0 · Founder/support | What job is valuable every month? | Competitors and current apps cover individual features; no Coffee Kit payments observed | Observe next real launch/lot change, then second task; merchant pays and renews for defined scope |
| P0 · Founder/support | What exactly would this merchant switch off? | Existing app detection is common; detection does not identify invoices or active use | Record current stack and workflow, actual bill, preserved features and replacement decision |
| P0 · Developer | Can Seal synchronize an approved physical swap safely before charge? | Line-edit API and all-tier API access documented; no atomic scheduler guarantee established | Test hold/cutoff/edit/read-back/renewal and concurrent cancellation on intended tier; correct order, price and stock |
| P0 · Developer/founder | Is a narrow owned engine a better product at sustainable cost? | Shopify reference app supplies scaffolding; production queue/email/version work remains | Bounded spike and operating estimate; same lifecycle cases, explicit owner for incidents, paid preference for unified offer |
| P0 · Designer/support/developer | What are the real allocation rules for clubs and customer-built boxes? | Studio rules remain hypotheses; the merchant's inventory units, deadlines and exceptions have not been observed | Recruit operational design partners; replay a normal and exception cycle, then shadow their forecasts before automation |
| P0 · Developer/support | Can the demand board reconcile subscriptions and physical rewards without double counting? | Available stock, unbilled cycles, issued rewards and potential reward demand are different classes | Source-linked counts, order/cycle transitions, stale-feed behavior, physical variant/location mapping and actionable alert tests |
| P1 · Designer/developer | Which discoverability improvements can the app actually publish and verify? | Native Shopify Catalog already distributes eligible products; Google requires no special AI markup | Audit existing fields and Product markup, source/approve missing coffee facts, verify permitted channel mapping and measure freshness |
| P0 · Support/developer | Which engine migrations are actually supported? | Contract/payment ownership is not ordinary data import | Confirm source/destination/gateway route, rehearse, reconcile dates/amounts/status, demonstrate no duplicate charge |
| P0 · Developer | What is canonical in current Coffeetale data? | Inspected bindings include custom.coffee, farm references and direct numeric axes |
Audit definitions/types and sample values; explicit map and conflict precedence; no destructive overwrite |
| P0 · Designer/developer | Can source review be faster without inventing coffee facts? | Proposed extraction workflow; model price examples only | Human gold dataset/holdout, provenance coverage, critical-fact correctness, omissions and measured review minutes |
| P0 · Developer | Do selected variants/plans survive the entire cart path? | Theme has option/quick-buy foundations; subscription builder backend is absent | Known coffee and club purchase tests with sold-out/invalid options; exact price/plan/quantity at checkout |
| P1 · Developer | Which subscription access and customer-data approvals apply? | Owning-app scopes and provider permissions are explicit boundaries | Confirm app distribution/scopes and protected-data requirements; document least-privilege access |
| P1 · Designer | Is the full flow comprehensible without founder help? | Supplied references and Mobbin patterns establish layout options | Merchant performs second task unaided; shopper identifies amount, cadence, first coffee and change policy |
| P1 · Developer | How much code is portable from Hydra? | Shared globals, helper sections and cart events are real dependencies | Small renderer extraction; Coffeetale version contract and one external-theme install work without missing helpers |
| P1 · Developer | Does every product participate in finder results correctly? | Existing helpers have 50/24 limits; chart needs numeric axes and a bounded collection | Explicit catalog eligibility; missing facts excluded honestly; exact vs closest matches labeled; larger-catalog test |
| P1 · Developer/designer | Can theme performance remain acceptable? | No production benchmark completed | Compare disabled/minimal/full on representative mobile hardware/network; measure layout and purchase responsiveness |
| P1 · Founder/support | What is the real support ceiling? | At 500 stores, ten minutes each consumes 83.3 hours/month | Log category-level time and onboarding; forecast with available support hours; eliminate repeated manual exceptions |
| P1 · Founder | Can Krown use the theme app add-on route? | Current route requires same partner organization and published app | Confirm actual organization ownership, publication eligibility and attachment behavior |
| P1 · Developer | What survives uninstall/theme change? | Merchant-owned facts can remain; app UI/services do not | Test export, uninstall and independent theme reading; communicate continuing engine/provider behavior |
| P1 · Developer/support | Which Klaviyo/Flow handoff is useful and permitted? | Existing connector can track events; plan/action limits matter | Identified event, duplicate handling, consent/suppression, stale stock and receipt verification; merchant flow is explicit |
| P0 · Designer/developer/support | Which loyalty route can deliver the promised coffee program? | API access can cost more than provider widgets; earning on renewals and redeeming against renewals are separate capabilities | Test per-bag/order earning, exclusions, redeem/refund, duplicate events and customer identity; price the full route; choose provider UI, API integration or a narrowly owned ledger |
| P2 · Developer | Can agency rendering reuse the same logic? | Shopify public data path exists; Coffee Kit API is proposed | Versioned read/config/matching contract, tenant isolation and CSS-free example on a real agency task |
| P0 · Founder/developer | What does each of the six subscription promises require? | Simple refill, curated, customer-built, personalized, gift and office references support distinct workflows; platform bundle surfaces differ | Complete the per-model acceptance cases in the subscription specification, estimate each increment and choose implementation order without conflating the models |
Subscription model boundaries
Fixed refill, curated club, customer-built box, personalized club, prepaid gift and office coffee have distinct shopper journeys and merchant rules. Calendar billing and finite pay-per-delivery are additional billing dimensions, not substitutes for prepaid gifting. Each changes what the buyer is promised. Separate offer configuration from its storefront layout. The subscription specification and reference atlas define the full scope.
The first rotating scope has one physical coffee per renewal, a disclosed stable club price, preserved size/grind and merchant approval. A specific-lot subscriber has different expectations from someone who chose a roaster-selected club. Record the authorization policy. A taste match can propose; it cannot grant consent or guarantee equivalence.
The subscription report's twelve cases are the minimum lifecycle review. Add provider-specific evidence and actual test outcomes to that matrix during implementation. A successful plan selection or contract API response does not prove the resulting renewal and inventory behavior.
Development release gates
These are proposed acceptance criteria. This research did not execute a production app, provider renewals or an extraction benchmark.
- Data: source evidence attached; unknowns remain unknown; approved field writes/read-back; concurrent merchant edit protection; recoverable failures and guarded undo.
- Commerce: Shopify-authoritative money and eligibility; exact variant/quantity/plan preserved; unavailable choices blocked; actual physical order/stock trace.
- Lifecycle: one supported engine route; idempotent jobs/events; cancellation races; payment/action-required errors; next-date and retry correctness; visible exceptions.
- Migration: route-specific eligibility, dry-run reconciliation, known scheduler ownership, no double charge, clear failed-record recovery and first-cycle verification.
- Storefront: a compatible Coffeetale version and one external theme; scoped assets; no unverified native-grid replacement; mobile and keyboard purchase paths.
- Privacy/ownership: appropriate Shopify/provider scopes, protected-data handling, tenant isolation, credential revocation, public/private field boundary and uninstall/export behavior.
- Operations: alert ownership, recovery runbooks, support hours and measured onboarding; app billing and merchant subscription billing treated as separate systems.
- Commercial: actual agreed price/scope, first payment, repeat value and renewal recorded separately; no substitute metric of screenshots, signups or attributed sales.
- Loyalty: immutable earning/redemption/reversal records; duplicate-event protection; quantity and discounted-item eligibility; refund-after-redemption policy; supported renewal and POS behavior tested separately. See the loyalty specification.
- Demand and alerts: scheduled demand reconciles with actual orders, physical reward exposure remains distinct from forecasts, stale data is visible, actions are confirmed by the owning provider, and duplicate events do not duplicate alerts. See the inventory specification.
What remains unknown after this study
No merchant willingness to pay, real app invoices, live contract migration, effective Coffee Kit provider credentials, lifecycle reliability, extraction quality, new-app performance or incremental sales lift has been established. Public pricing and APIs can change. Dataset identities require current qualification. These limits are already reflected in the build sequence and sales claims.
The research does establish a reproducible candidate screen, a concrete competitor baseline, credible implementation routes, existing frontend reuse with known dependencies, a product/operating model, and reviewable visual journeys. Those are the inputs for the next investment decision.
Source: DECISIONS_AND_OPEN_QUESTIONS.md The complete Markdown handoff and private datasets remain in the local project. This web edition includes selected supporting visuals and scenario downloads.