💡 Market Event Programming Calendar for Community Engagement

[github-actions[bot]]

Summary

Managers can publish market events — cooking demos, live music, farm tours, kids activities, seasonal festivals — that appear in the customer discovery feed alongside vendor listings. Events drive foot traffic on slower days, create shareable content for organic growth, and differentiate Markets from admin-only competitor tools. Vendors can be linked to events they participate in, creating cross-promotion.

Market Signal

Research shows vendors who lead workshops at farmers markets see 25-30% daily sales increases, and markets with regular educational programming report higher attendance and longer visitor stays. The competitive landscape is clearly split: Seen Markets and Eventeny focus on vendor management without event discovery, while Eventbrite and Meetup handle events without market context (seasonal schedules, vendor linkage, role-based access). No farmers market app integrates event discovery with real-time vendor status — this is a structural gap.

User Signal

The UX design specification identifies "market-day anticipation" as a key design opportunity and push notifications that convert passive followers into active market-goers as a core engagement loop. The PRD's growth features mention "intent-based shopper planner" — events are a natural planning signal. Customer push notifications for events ("Cooking demo with Green Valley Farm at 10am!") extend the engagement loop to non-followers, serving as a customer acquisition tool alongside the vendor check-in retention tool. 55% of weekend market visitors have children — family-oriented programming is a strong draw.

Technical Opportunity

This is a CRUD extension of the existing market profile domain. A new market_events table (linked to markets and optionally to vendors), a GraphQL schema addition in market.graphqls, and a new EventCard component in components/market/. Events publish domain events via the Go event bus (internal/events/) for push notification dispatch to market followers. The existing ActivityFeedItem component (UX-DR9) already supports role-specific variants — events add a new variant. PostgreSQL audit triggers attach automatically to the new table.

Assessment

Dimension	Score	Rationale
Feasibility	high	Standard CRUD feature; one new table, one new component, one new feed variant
Impact	med	Drives foot traffic and organic growth; proven 25-30% vendor sales lift from programming
Urgency	med	Competitive differentiator; low effort makes it viable for early releases

Adversarial Review

Strongest objection: This distracts from the core "confirm and go" coordination mission. Markets should focus on reliable vendor status, not become an event discovery platform.

Rebuttal: Events don't replace the coordination loop — they augment it. A cooking demo is another reason to confirm-and-go. The implementation cost is minimal (one new table, one new card component, one new feed item variant). The key is scoping: events are a field on the market profile, not a separate event management system. No RSVPs, no ticketing, no complex scheduling — just title, time, description, and optional vendor link. Markets with programming have measurably higher attendance, directly supporting the north-star metric.

Suggested Next Step

Add a market_events table to the data model with fields: market_id, title, description, start_time, end_time, vendor_id (optional FK), event_type enum (cooking_demo, live_music, kids_activity, farm_tour, seasonal_festival, other). Design the EventCard component following the MarketCard pattern from UX-DR7.