💡 Customer Shopping List Market Trip Planner

[github-actions[bot]]

Summary

Customers create a shopping list of items they need (e.g., tomatoes, honey, sourdough bread), and the app matches items to vendors at nearby markets, suggesting which market day will satisfy the most items on their list. This transforms discovery from browsing-one-vendor-at-a-time into planned, efficient market trips — directly serving the "confirm and go" experience with a "plan and go" layer.

Market Signal

Too Good To Go (100M+ users, 170K+ stores) demonstrates that structured food discovery (browse → reserve → pickup) outperforms passive browsing. Samsung Food's Vision AI matches ingredients to recipes, showing the "what can I get/make?" UX pattern gaining traction. Localize (200K monthly downloads, $100K/month revenue) proves consumer demand for local food discovery but offers only a farm directory, not list-driven planning. No farmers market app offers shopping list → market matching. The "intent-based shopper planner" is explicitly listed as a Growth Feature in the Markets PRD.

User Signal

The PRD's customer persona Rachel doesn't just want to confirm one vendor — she has a mental shopping list. FR23 (discover vendors by product intent) provides single-item search, but customers think in lists, not individual searches. The existing ideas for Product-Level Following (#394) and Seasonal Produce Discovery (#362) address adjacent needs but not list-driven planning. Customer failed-trip feedback (#70) could surface which list items went unfulfilled, closing the planning → execution → feedback loop. Average household spending of $32 per market visit (up 15% from 2019) shows customers are planning substantial purchases, not impulse buys.

Technical Opportunity

FR12 (vendor baseline product offerings) already requires vendors to define their product catalog. The matching algorithm queries vendor_products for each shopping list item, scores markets by list-item coverage percentage, and ranks by distance + coverage. Apollo Client's normalized cache makes client-side matching fast for small datasets. The GraphQL schema needs a new shoppingListMatch query that accepts product category IDs and returns ranked market/vendor results. This builds naturally on the existing search infrastructure (FR21-23) and the vendor_products table in the data model.

Assessment

Dimension	Score	Rationale
Feasibility	med	Requires product catalog + matching algorithm; catalogs may be sparse initially
Impact	high	Core experience enhancement; directly extends "confirm and go" into "plan and go"
Urgency	med	Explicitly listed as PRD Growth Feature; builds on existing search infrastructure

Adversarial Review

Strongest objection: This requires vendors to maintain accurate, granular product catalogs — which conflicts with the exception-first principle that minimizes vendor maintenance burden.

Rebuttal: The matching operates on baseline product catalogs (FR12), not real-time inventory. Vendors set their catalog once (they already must for their vendor profile) and only update when their permanent offerings change. The optimizer shows "likely available based on vendor's catalog" with freshness timestamps indicating when the catalog was last confirmed. Match by product category (produce, baked goods, dairy) initially, not specific items (heirloom tomatoes). Category-level matching works even with sparse catalogs. Precision improves organically as vendor data quality grows.

Suggested Next Step

Design the shopping list data model (customer_shopping_lists, shopping_list_items with product_category_id references). Prototype the matching algorithm: for each list item category, find vendors offering that category at markets within the customer's search radius, then score markets by coverage percentage. Start with category-level matching; refine to product-level as catalog density increases.