💡 Multi-Market Vendor Earnings & Schedule Intelligence

[github-actions[bot]]

Summary

A unified dashboard for vendors who sell at 3-5+ markets weekly, showing cross-market schedule conflicts, earnings trends by market, and data-driven recommendations on which markets to prioritize. Addresses the underserved multi-market vendor segment identified in competitive research — a segment no incumbent serves with a vendor-centric operational intelligence view.

Market Signal

Competitive research identifies multi-market vendors as a structurally underserved segment — vendors selling at 3-5 different markets weekly lack unified scheduling and performance dashboards across markets. Barn2Door ($11.6M funded) and Local Line ($79-199/mo) focus on e-commerce sales channels, not cross-market operational intelligence. GrownBy (cooperative model) focuses on community buying, not vendor operations. No incumbent provides a vendor-centric view across multiple markets. The D2C farm delivery model is collapsing (Otipy $50M+ failure, GoLemon shutdown July 2026), validating the coordination-first approach over e-commerce. Sources: Barn2Door vs Local Line, GoLemon Shutdown.

User Signal

Brad (vendor persona) is described as a "multi-market organic produce vendor." The PRD's vendor value proposition focuses on discoverability and follower flow, but doesn't address the operational reality of managing attendance across multiple markets. FR14 warns about same-day check-in conflicts (vendor already checked in at another market), implying the architecture already anticipates multi-market vendors. The existing idea #361 (Cross-Market Vendor Week-at-a-Glance) covers schedule visualization but not earnings intelligence or market prioritization recommendations. Idea #397 (Vendor Demand Signals) focuses on customer-facing demand, not vendor-facing operational intelligence.

Technical Opportunity

The planned architecture includes vendor-market associations (FR13), check-in history (FR14), and audit logging (FR35-36) that naturally produce the data needed for attendance and performance analytics. A vendor dashboard screen in the (vendor) tab group would consume existing GraphQL queries with aggregation resolvers in the Go backend. The domain event bus (internal/events/) already captures check-in/checkout events that can be aggregated for trend analysis. Earnings tracking starts as a single optional numeric field on the checkout event — consistent with exception-first UX where everything is skippable.

Assessment

Dimension	Score	Rationale
Feasibility	med	Core schedule features use existing data; earnings requires new optional field on checkout flow
Impact	med	High value for the multi-market vendor segment; moderate value for single-market vendors
Urgency	med	Becomes critical at the 12-month target (160 vendors across 20 markets); design-now, build-later

Adversarial Review

Strongest objection: The app has zero vendors and zero markets today. Building analytics dashboards before there's data to analyze is classic premature optimization. Also, "earnings" implies Markets knows about transactions — but the PRD explicitly defers e-commerce checkout. Without transaction data, earnings tracking requires manual vendor input, which contradicts the exception-first UX philosophy.

Rebuttal: The proposal is for post-MVP roadmap planning, not immediate implementation. The "earnings" component would start as vendor self-reported market-day revenue (a single optional field after checkout — consistent with exception-first UX where it's easy to skip). The core value is schedule intelligence and conflict avoidance, which uses data Markets already captures through check-in/checkout flows. The 12-month target of 160 vendors across 20 markets means multi-market conflicts will be real by month 6. Starting the data model early (adding the optional field to the checkout event schema) avoids a painful migration later.

Suggested Next Step

Extend idea #361 (Cross-Market Week-at-a-Glance) with earnings tracking and schedule conflict detection. Add an optional market_day_revenue field to the vendor checkout event schema. Design the aggregation resolvers in the Go backend to support weekly/monthly trend queries.