Coffee Kit — the complete solution for selling coffee on Shopify

Research and product decision · 12 November 2026
Prepared for Krown's three-person team: design, development and support. This is a business and product proposal supported by research, a reproducible market screen and a visual prototype. It is not a released Shopify app or a claim of validated demand.

Product vision: begin with the full product blueprint, including six distinct subscription journeys and first-class loyalty. The narrower pilot below is an investment and implementation sequence, not the limit of the product being presented. The Subscription Studio specification and loyalty specification expand the full functionality and its acceptance requirements.

Operational dependency: advanced clubs and recurring boxes must be developed with real merchant design partners. Demand planning must cover upcoming cycles and physical loyalty rewards, with clear stock states and actionable alerts. The merchant discovery plan and demand/inventory specification replace any implication that the studio's imagined settings are already validated. Coffee data and AI discoverability is a core product capability, not just an import feature.

The decision

Pursue Coffee Kit as a coherent coffee-selling product, with the ambition to become the preferred solution for selling coffee on Shopify. Test a $99/month offer before funding the whole suite. Its strongest proposed value is the connection between accurate coffee information, a buying experience that helps customers choose, and a subscription experience that remains correct as the coffee changes.

The distinctive demonstration is a second coffee launch: a merchant approves a new lot, the same facts appear across their selling experience, eligible customers can find it, and the next club selection is prepared with the right physical product, size, grind and price. Measure that entire task against the merchant's best existing setup. Attractive blocks, cheap extraction and a subscription selector are individually easy to substitute.

Existing subscription usage establishes a competitive benchmark and a switching hurdle. It does not require Coffee Kit to remain an accessory forever. Design a product merchants can move to; earn each replacement by improving their work, their customer's experience or their total cost. Retain specialist services where rebuilding them would weaken the coffee product.

My initial architecture choice is a provider-independent coffee model, purchase journeys over real Shopify variants/plans, and a bounded comparison of Seal integration against a narrow owned engine. Test Seal first because its documented API access and price make it a credible baseline. In parallel, estimate the specific remaining work in Shopify's reference app. Choose the owned engine if a unified coffee club wins paid preference and reliable pre-charge rotation cannot be achieved economically through a provider. Do not quietly turn the initial purchase journey into a promise of automated renewals.

Do not initially build general loyalty infrastructure, an email platform, unlimited theme customization, cross-platform migrations or roast operations. This is a sequencing decision. The long-term product can feel complete through supported integrations and a consistent experience without owning every underlying service.

1. Who the product is for

The first buyer is an established Shopify seller of coffee beans: an own-brand roaster or a specialist multi-roaster retailer, with an online customer base and a real next catalog or club change. Their business already gives them reasons to care about product information, discovery and repeat purchase. Separate those two merchant types during interviews: choosing stock from other roasters differs from selling one's own seasonal lots.

A café selling mostly prepared drinks, a stable two-product shop, an equipment retailer and a large international subscription operator have different needs. They can be future segments; they should not define the first configuration system. Counter-service stamps and roasting logistics would create another product and support model.

What the supplied exports establish

The analysis processed 1,385,355 rows across both complete CSVs, then deduplicated domain/platform identities and audited sampled exported text. “Active” below is StoreLeads' exported status. Language and app detections are screening signals, not verified current orders or payment demand.

The uncategorized export does contain coffee matches: 1,952 raw store names contain “coffee”; 2,434 rows match name or domain. After identity deduplication and active-status screening, it adds 1,155 strong-coffee identities, but only 31 roaster-language primary records. The audit found substantial incidental matching in this source. Do not turn every coffee-name match into a roaster lead.

The market agent reviewed 197 stratified candidates and 60 negative controls from exported text. It found both false positives and language/sparse-text misses. The stratified sample is not a population precision estimate. A private 36-record screening shortlist is supplied without contact columns. Counts, source hashes, formulas and reproduction commands are in the market report; the verified aggregate dataset (local handoff artifact) is the canonical version.

Commercial implication: there is a credible population to investigate, but the current exports do not prove a serviceable market large enough for $1M ARR. At $99, 842 paying stores produce that ARR. That is about 14% of the broad 5,990 roasting-language screen and 32% of the 2,606 specialty screen, before disqualifying anyone. Krown distribution can launch the experiment; broader acquisition is necessary for the larger ambition.

2. The product concept

Why pursue this direction instead of the earlier alternatives?

The supplied Krown history describes the current full Studio companion suite at a proposed $99, not just an old $29 bundle widget. Judge the whole coherent offer. Its reported 12,007 active portfolio domain rows and 5,274 Local rows are historical research outputs from that dossier; this study did not rerun the portfolio/support archive. They are not directly comparable to the deduplicated coffee screens above.

Coffee Kit and Studio can share field mapping, theme capabilities, compact renderers, preview, connection health and support tooling. They should not share an indiscriminate product menu or an assumed buyer. Do not merge café subscriptions, generic cart upsells and a template showroom just because Hydra can render them. The decision favors Coffee Kit's testable vertical workflow, not a proven larger financial opportunity. Supplied Krown direction history (local handoff artifact).

Approve your coffee once. Sell it coherently wherever customers choose and buy. Keep the experience current when your coffee changes.

The app should organize seven connected jobs:

Settings contains field mappings, style defaults, permissions, exports, billing and developer access. Loyalty is a dedicated product surface with a meaningful program and customer preview. Its backend delivery choice is tracked independently from the visual product concept; empty placeholder destinations are not sufficient.

A representative merchant journey

1. A roaster installs Coffee Kit and sees existing coffee products. They select one coffee to improve, without rebuilding Shopify's whole product editor.
2. They add a bag photograph or source sheet. The app shows proposed facts beside the exact source. Uncertain or missing information stays visible; the app does not invent sensory scores.
3. They approve fields and map size/grind to real Shopify variants. Prices, inventory and publication remain explicit merchant decisions.
4. Their coffee card, detail blocks and finder read the same approved data. The merchant previews one shared style in Coffeetale and the supported external-theme adapter.
5. They choose a purchase model: same-coffee refill or a club whose terms allow the roaster to choose each cycle. The customer sees the first coffee, size, grind, cadence, recurring amount and management route.
6. When a lot ends, the app identifies affected selling experiences and, where supported, upcoming subscriptions. It proposes eligible replacements and shows the operational consequences before anything changes.
7. A merchant-approved club selection reaches the real order and stock record. Specific-coffee subscriptions follow their disclosed substitution/consent policy; a taste similarity score is not authorization to change a contract or price.

This is the recurring value hypothesis. It must be observable after the initial import and setup.

3. What makes merchants switch

The proposed moat is a reliable, maintained coffee workflow plus Krown's distribution and design execution. It is not exclusive ownership of the merchant's data. The facts should remain portable. Long-term defensibility comes from doing the difficult repeated task better: accurate mappings, consistent presentation, eligible recommendations, safe coffee transitions and low support effort.

The product must beat competent incumbents. Coffeefy advertises free coffee presentation, CoffeeRx a $14.99 finder, Andeo connected coffee matching and Curobi coffee clubs/boxes. Generic quizzes and loyalty products already have named coffee merchant reviews. Recharge already documents rotation workflows. These are direct comparison targets, not empty spaces. Coffeefy, CoffeeRx, Andeo, Curobi, Recharge swaps.

“The #1 solution” is a useful ambition. Public copy should describe the concrete advantage until independent evidence supports a leadership claim. The proposed first headline is “Your next coffee, ready to sell.” The supporting story is reviewed facts, thoughtful buying experiences and coffee subscriptions that can evolve with the catalog.

Switching as a product and a service

Offer a switching assessment, not an unconditional one-click migration promise. Inventory the current theme, fields, provider, contract types, payment gateway, discounts, delivery rules and customer portal. Classify the move as presentation-only, data/experience replacement, new-club enrollment, or an actual engine migration. Price and schedule these separately.

Agents can prepare field maps, compare exported records, draft migration instructions, flag anomalies and generate reconciliation reports. Support owns the merchant conversation and approved checklist. The developer owns provider access, contract/payment mapping, cutover and reconciliation. Payment credentials are not ordinary CSV fields, and Shopify's own-contract scopes do not grant control of another app's subscriptions. Contract ownership, payment-method migration.

Rehearse with representative cases, confirm the supported provider migration route, reconcile next-charge dates and amounts, prevent both schedulers from charging the same cycle, and retain an exception/rollback plan. A completed migration is not merely a successful import. Start with new clubs or presentation changes where practical; undertake engine migration only when the measured improvement warrants it. The subscription report supplies the provider and migration evidence.

4. The subscription decision, in depth

The long-term product can own coffee subscriptions. The immediate decision is how much ownership creates useful differentiation for this team.

The full Subscription Studio includes refills, curated tiers, customer-built recurring boxes, personalized clubs, prepaid gifts and office programs. These need different shopping layouts and configuration rules. Wogan's supplied sequence shows a genuine multi-coffee recurring selection and separate recurring cart lines; Nordic Brew Lab shows composed club tiers; Tanat shows guided club configuration. Those are richer product models than a single recurring selector. See the six-model reference atlas and complete functionality specification. The route comparison below determines how to implement these models over time, rather than whether to show them in the product vision.

Seal's public matrix explicitly includes API/webhooks on every tier. Appstle documents approved partner tokens that bypass merchant API charges, but approval and feature entitlements remain to be established. Loop puts API access on Pro at $399/month plus 0.75%; Skio's monthly Scale offer is $599 plus 1% and $0.20. These expensive API defaults would undermine the small-roaster offer. Seal pricing/API, Appstle partner framework, Loop, Skio.

At an illustrative 500 monthly subscription orders worth $15,000, proposed Coffee Kit at $99 plus Seal's $24.95 tier totals $123.95, assuming the total subscription count fits that tier. Coffee Kit plus Loop Pro totals $610.50; plus Skio monthly Scale $948. These are different offers with different coverage, not like-for-like quotes. Existing provider spend and additional spend caused by Coffee Kit must be shown separately. See all 24 scenarios.

A narrow engine is not a payment processor built from scratch

Shopify supplies checkout, vaulted payments, contract and billing primitives. Its reference app supplies substantial UI and renewal scaffolding. The inspected source still needs production work, including real email delivery, secured job execution, pinned versions and adaptation of legacy contract editing. That is concrete engineering to estimate, not a reason to dismiss ownership categorically. Reference app, core responsibilities.

The bounded owned scope is: domestic shipping, one currency, verified gateway, pay-per-delivery, a few cadences, fixed-SKU refill and one merchant-selected physical coffee per club cycle. Include pause/skip/cancel, payment/address management and exception handling. Defer prepaid gifts, mixed boxes, international rules, variable-price automatic replacements, pickup scheduling and POS enrollment until the base operates reliably.

The merchant chooses the coffee before billing. The resulting order contains the actual physical variant. A permanent club SKU with a new text label is insufficient stock accounting. A missing grind/size, sold-out variant, cancelled contract or incomplete update holds the operation for a defined resolution. The system must not charge first and discover the coffee mapping later.

Current platform facts that change the design

• Free Shopify Subscriptions now supports specific billing weekdays/dates and expiry after 2–1,000 successful orders. Native is a strong baseline; finite pay-per-delivery is still distinct from a prepaid gift. Current native plans.
• The 2026-10 calculation API supports newer contract editing and documented bundle edits. Providing a lines array replaces the stored line list, so retained lines require correct restatement. Migration guide, bundle contract edits.
• Merchant bundle documentation still restricts purchase-option compatibility. A new contract-edit capability does not establish that a particular initial checkout, bundle app and renewal combination works. Test the exact representation. Merchant bundle limits.

Before selling automatic rotation, run the 12 lifecycle cases: stock loss, deleted variants, payment failures, duplicate/time-out events, concurrent cancellation, price changes, delivery changes, date edges, finite/prepaid distinctions, mixed carts, revoked access/uninstall, and refunds. These are acceptance requirements, not tests already passed.

5. Data, AI and discoverability

Store approved public coffee facts in merchant-owned Shopify fields/metaobjects, reusing compatible existing and standard fields. Keep evidence, jobs, provider secrets and private customer preferences in appropriate private storage. App-owned definitions do not become durable merchant-owned data merely because merchants can edit them. On uninstall, approved content can remain while app blocks and hosted services cease. Explain that distinction plainly. Shopify field ownership.

Keep product, physical variant, coffee lot, roast offering and sensory assessment distinct. Price/stock come from Shopify; tasting words come from cited sources; numeric sensory scores need an actual assessment. Support blends/cooperatives and missing facts. An elegant sparse card is better than a complete-looking invented one.

The review UI distinguishes observed, normalized, suggested and unknown values, shows the source page/region, and handles conflicts with existing merchant edits. Publishing is an explicit, idempotent action with read-back and a guarded undo. An agency can consume approved public data through Shopify and later a versioned Coffee Kit configuration/finder interface without using our styled renderer.

The AI cost is likely smaller than support and review cost, but accuracy remains untested. Using observed Gemini pricing and illustrative 8,000 input/1,500 output tokens, two passes plus a 20% retry allowance cost about $0.01476 per import in inference, or $1.48 per 100. This excludes document processing, storage, failures and human work. Compare current multimodal providers on 100 representative sources with a holdout, measuring fabricated facts, omissions, review time and full cost. Do not choose a provider solely from its advertised token rate. Detailed extraction design and current model sources.

For discovery, deliver useful initial HTML, consistent Product/Offer data, accurate availability, internal links and well-structured coffee facts. Do not promise AI rankings or citations. Google does not require special AI markup; local café search also depends on location information beyond coffee products. Google AI guidance, Product markup.

The product pitch should explicitly name coffee data management and SEO/AI discoverability. Shopify already provides eligible product distribution through Catalog and supported AI channels, including custom data mapping; Coffee Kit improves the coffee facts, consistency and maintenance that feed those surfaces. Do not sell native distribution as an exclusive Coffee Kit invention. Build a source-review and data-health workflow with concrete diagnostics, not a fictional AI ranking score. Shopify Catalog mapping, full discoverability specification.

Demand planning is part of the recurring product

Subscriptions and free-coffee rewards compete with ordinary sales for physical stock. Show due unbilled cycles, unallocated clubs, issued physical rewards and near-threshold customers separately. Monetary vouchers are not a count of coffee bags. Forecast scenarios are not reservations, and a proposed signup stop is not an existing provider billing hold. The demand specification covers the backend event flow, record ownership, reconciliation, stock checks, alerts and acceptance cases.

Begin with visibility and merchant-assisted review. Do not promise automatic capacity protection until stock sharing, concurrent purchases, location rules and the engine's actual behavior are tested. Observe real club and box merchants, replay their past cycles and run a shadow forecast before automating. This adds operational scope beyond the original catalog/enrollment allowance and must be estimated separately.

6. What to build, integrate and defer

Klaviyo should receive reviewed context and an identified eligible customer event, with consent respected by the actual flow. A catalog publication event alone does not identify recipients. A QR code can open a useful finder or menu, but does not create a POS identity or loyalty ledger. A pickup-availability block does not reserve a time slot. See the integration responsibilities and costs.

Coffeetale is a distribution and visual advantage, with a versioned compatibility contract. External themes receive small scoped renderers and assets. Do not copy the entire Hydra runtime into an app extension or promise zero performance impact. Native theme functionality already sold to merchants should retain its value. The app earns recurring payment through new workflow and services.

The remaining ideas from the brief have explicit places:

These additions should reuse approved facts and style. They do not each require a separate data model or top-level app section on day one.

Loyalty delivery choice

Loyalty now has its own full product specification: merchant earning/reward rules, customer progress and wallet, redemption, subscription eligibility, café/POS distinctions and reversals. The desired Coffee Kit interface should be designed and demonstrated even while choosing its ledger.

Fresh provider research finds Appstle's $10–$30 plans a plausible affordable provider-interface path, including documented per-item earning. Its bespoke API access is a separately priced add-on with no published price. Rivo and Smile custom developer access sits on much more expensive plans. An inexpensive installed loyalty app therefore does not automatically enable the full custom Coffeetale card. Compare a supported provider interface, an affordable confirmed API agreement, and a deliberately narrow owned bag-reward ledger. This is an architectural decision, not a reason to omit loyalty from the product. Loyalty evidence and exact gates.

Subscription earnings and next-renewal redemption must be proven separately. Refunds, customer merges, reward-code lifecycle and discounted free bags can create double benefits if handled superficially. The ledger and eligibility rules must be deterministic; AI can help configure/review them but does not invent balances or authorize redemption. An owned ledger and advanced subscription models add scope beyond the initial-app cost allowance.

7. Price and business model

Test one clearly scoped $99/store/month offer, with no revenue percentage initially. Show existing provider charges and any required upgrades alongside it. This is a proposed price, not validated willingness to pay. Do not create five plans before knowing which job repeats.

If merchants pay for repeated catalog preparation but not the connected buying workflow, test a narrower $49 offer separately. If they value only setup, consider a tightly capped one-time service or theme-contained feature. These are alternative businesses, not evidence that the $99 proposition succeeded.

Avoid “replace all your apps.” For example, replacing a $39 quiz with $99 Coffee Kit while retaining the same subscription, email and loyalty tools raises the bill by $60. A switch is justified by measured value or actual eliminated costs. Any broader owned-engine package needs its own complete feature/cost comparison.

Actual Shopify fees differ from the reserve scenario: eligible first-$1M lifetime app-revenue treatment, then 15% share, plus 2.9% processing and applicable adjustments. Confirm Krown's aggregate account position. At a simple 17.9% fee scenario, $99 less $5 infrastructure and $15 support yields $61.28 contribution. Do not budget mature margins as though the early threshold resets annually. Official fee schedule.

An owned-engine sensitivity assumes 240 additional engineering hours at $60/hour, 24-month amortization, 16 maintenance hours/month, $3 infrastructure and ten support minutes/store. Its incremental burden is $39.20/store at 50 engine stores, or $23.60 at 100. This is an illustrative cost model, not a delivery estimate; the reference-app spike replaces those inputs. Migration/onboarding is also labor: include it once in CAC or charge a fixed scoped service, rather than hiding it in recurring margin.

The economics workbook and assumptions make the base scenarios reviewable. The economics note explains break-even, churn and merchant contribution without confusing attributed sales with incremental profit.

8. A three-person execution plan

Use a staged 12-week pilot window, with timing contingent on technical access and delivery. It is a planning sequence, not a committed App Store launch date.

The developer owns data/purchase correctness, provider work and observability. The designer owns review and buyer journeys, shared storefront rules and reusable demos. Support owns qualification, onboarding, documentation and cohort records. The founder joins consequential product/technical decisions. Do not make every lead a custom theme project.

Build budget and capacity, before a technical estimate

The following are planning allowances selected for discussion, not measured estimates or quotes. Replace them with the architecture spike, backlog and actual team rates. Reusable theme code reduces some storefront work; it does not remove app authentication, background jobs, tenant isolation, billing, migrations, review and support tooling.

Do not add these allocated hours to the same salaries a second time in a cash budget. At 25 product-engineering hours/week after other obligations, 312–488 developer hours imply about 13–20 weeks of engineering capacity, before approval delays and scheduling conflicts. Therefore the 12-week table is an experimental cadence with early prototype evidence and a readiness-dependent live cohort, not a promise that the entire app ships in twelve weeks. If owned subscriptions is selected, add its separately estimated scope; the subscription paper's 240-hour scenario alone adds roughly ten engineering weeks at that availability, before overlap/reuse. Funding, runway and exact team availability were not provided and should be entered before a build commitment.

Full-vision capacity is a separate decision. Customer-built recurring boxes, prepaid entitlements, preference-led renewal selection, a custom loyalty ledger/POS path and broader theme/provider support are not all included in the initial allowance. For a funding discussion, model explicit total-engineering scenarios of 800 / 1,200 / 1,600 hours: at $60/hour, $48k / $72k / $96k of engineering time, and at 25 hours/week, 32 / 48 / 64 weeks before parallelism or availability changes. These are sensitivity cases, not estimates of how long Coffee Kit will actually take. Design, support, infrastructure and acquisition are additional. A measured backlog must choose the operational engines and eliminate duplicate work before any total is approved. The rich concept site is intended to test which of this larger product earns switching demand, while the initial release funds and validates a coherent subset.

Reserve a proposed 22 commercial team-hours/week: support 12, design 6, developer/founder 4, separate from product engineering. Cap assisted onboardings at two weekly and active pilots at 8–12. At an assumed $30/hour, 13 weeks of that allocation has $8,580 economic labor cost, even if incremental cash spend is low. A proposed $1,000 research/tool contingency is a budget idea; no spend or campaigns have been initiated.

For a switch pilot, use a separate capacity limit and measured labor budget. A two-hour standard setup and a multi-day contract migration cannot share an unlimited free onboarding promise. Publish a supported migration matrix only after the first repeated successful route.

A concrete service hypothesis is $750 once for up to 500 simple contracts, one supported source/store/gateway/currency, one rehearsal and cutover, plus first-cycle monitoring. The subscription study models $420 delivery cost and $330 contribution before acquisition/fixed overhead; five extra technical hours nearly consume that contribution. Exclude prepaid/gifts, processor changes, bespoke boxes and analytics-history reconstruction. This is a price to test after the route exists, not a current migration offer. Existing contracts and next dates must reconcile, and uninstalling the source is not a reversible pause: Shopify documents cancellation of remaining app-owned contracts 48 hours after uninstall. Migration scope and sources.

9. Marketing, selling and automation

Lead with the complete task and show the merchant's own coffee. A generic feature list is less convincing than a comparison of their current launch/change and the proposed workflow.

1. Existing Krown relationships: manually qualify 20–30 candidates, confirm theme versions and actual relationship, then demonstrate one next coffee. Warm-channel results remain separate from external demand.
2. Coffeetale launch: demonstrate theme plus optional app value. Shopify's new theme app add-on route may help distribution, subject to publication and same-organization requirements; it does not guarantee installs. Official announcement.
3. Two specialist agencies: provide a field map, reusable demo, scoped installation and plain rendering path. Keep bespoke storefront/migration work with a partner when it exceeds product scope.
4. Selected external roasters: tailor a comparison to a verified current job and current provider. Offer switching assistance when the benefit and technical path are clear.
5. Search/listing/content: publish guides from real solved tasks, then permissioned cases with measured time/value. Paid ads wait until activation and retention are understood.

Suggested pilot pitch:

We're building Coffee Kit to make selling coffee on Shopify feel like one connected job: approve your coffee details, help customers choose, and keep subscriptions aligned as coffees change. We'd like to compare your next launch or club change with your current setup, using your own coffee. The initial offer we're testing is $99/month for a defined supported scope. We'll show the total bill and any switching work before you decide.

The support/sales role should ask what was hard in the last actual change, which tool already solves it well, what must be preserved, and what would justify a switch. A sales call ends with a defined next task or a recorded reason not to proceed. “Interested” is not paid activation.

Agents can qualify public facts, draft reviewed personalized messages, prepare source-backed previews, summarize authorized calls, map data, draft support answers and report the cohort funnel. Humans approve merchant facts, commercial promises and consequential changes. This project has sent no outreach and changed no merchant account. See unsent pitches, channel plan and operating table.

Use one private table/CRM with channel, qualification, actual task, theme/provider, quote, first-value date, payment/renewal dates, support minutes, migration effort, next action and loss reason. Track qualified → activated → paid → repeated value → renewed. Report founder-assisted time. Later test self-serve and agency acquisition: 300 individually delivered demos/month to win 30 shops would exceed this team's capacity.

10. Design and developer handoff

Use real current Polaris web components for the admin prototype and eventual embedded app. The current docs are v2.0; the versioned CDN avoids the legacy unversioned 1.x entry point. The standalone prototype demonstrates components and state changes; it is not authenticated Shopify admin. Component library, versioning.

The storefront should use actual supplied Coffeetale/Figma references and verified theme assets. New mockups follow Coffeetale's typography, spacing, controls and coffee-card language. Do not restyle Shopify admin as a coffee shop; maintain a clear boundary between native merchant controls and the branded customer preview.

The detailed product strategy and handoff specifies entities, jobs, interfaces, screen states and acceptance work. The UX/assets audit distinguishes existing implementation from design references and backend work still required. The data architecture and subscription report supply the difficult contracts and test cases.

Required interactive wireframes are: overview; source review with conflicting/missing facts; shared experience styling and preview; subscription functionality builder; customer enrollment; and a proposed next-lot review with explicit price/eligibility consequences. Include empty/error/unsupported states, mobile layouts and a visible demo label. Forms must change the demo state; no production Shopify writes or fabricated payment success.

11. What would change this recommendation

The next investment decision needs merchant tasks, actual payments and live lifecycle evidence. This research supplies the comparison, product definition and prototype needed to obtain that evidence; it does not manufacture those outcomes.

Evidence and deliverable guide

• Market screen, audit and reproducibility
• Subscription routes, API gates, costs, lifecycle cases and migration
• Competition, reviews, integration boundaries, 90-day marketing and pitch drafts
• Data, AI, discoverability and agency architecture
• Economics and validation assumptions
• Product, developer and designer handoff
• UX, actual theme assets and Mobbin references
• Full product vision, six-model subscription specification and reference atlas
• Loyalty product specification and provider evidence

Public offers and documentation were checked on the research date. Provider capabilities are documented or advertised unless explicitly described as tested. StoreLeads counts are deterministic calculations from the supplied exports. Business prices, cost assumptions and pilot gates are proposals. No interviews, provider integration tests, AI accuracy benchmark, production performance benchmark, paid demand or conversion uplift were established in this study.

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