💡 Smart Category-Aware Notification Preferences

[github-actions[bot]]

Summary

Allow customers to set product-category preferences that filter their notification stream, so they only receive check-in and availability alerts for the types of products they care about. Instead of getting 30 notifications when 30 vendors check in at a followed market, Rachel gets 3 — for the egg vendor, the honey vendor, and the herb vendor she actually visits.

Market Signal

Notification fatigue is a leading cause of app uninstalls — industry data shows 71% of users cite excessive notifications as a reason for disabling or uninstalling apps. No farmers market app offers category-filtered notifications. DoorDash Zesty uses AI-curated recommendations to reduce noise; this feature achieves a similar outcome through explicit user preferences, which is more appropriate for a trust-focused platform where users want control rather than algorithmic curation. The broader trend across consumer apps is toward intelligent notification management, not just on/off toggles.

User Signal

The PRD specifies notification preference controls (FR43) but doesn't detail category-level filtering. The customer onboarding flow (FR20e) already collects product preferences (FR42b) — but currently those preferences don't gate notifications. As the platform scales toward its 12-month target (20 markets, 160 vendors, 1,000 customers), notification volume will grow proportionally. Without category filtering, a customer following a market with 30+ vendors would receive overwhelming check-in notifications every Saturday morning — exactly when they need clear, actionable signal.

Technical Opportunity

FR43 already requires notification preference controls, and the event bus architecture (internal/events/) provides the natural interception point for filtering. The customer onboarding flow (FR20e) already includes product preference selection — these preferences can be reused as notification filters without additional user input. The FCM dispatch handler (internal/notify/) can apply category filters before sending, reducing both notification noise and FCM costs. This feature makes existing onboarding data actionable rather than decorative.

Assessment

Dimension	Score	Rationale
Feasibility	med	The onboarding flow already collects preferences, and the event bus provides the filtering interception point. Main work is wiring preferences to the notification dispatch path and building a preferences UI.
Impact	high	Directly prevents the #1 cause of app uninstalls (notification fatigue). Makes the platform smarter as it scales. Puts existing onboarding data to productive use.
Urgency	high	Should be designed before the notification system goes live, not retrofitted after users have already been overwhelmed. Building the filtering infrastructure into the initial FCM dispatch handler is far cheaper than adding it later.

Adversarial Review

Strongest objection: At MVP scale (40 vendors, 250 customers), notification volume is too low to cause fatigue. This is premature optimization for a problem that doesn't exist yet.

Rebuttal: Product-category preferences are table stakes UX even at small scale. The user story is immediate: Rachel follows Riverside Market (30 vendors) but only cares about eggs, honey, and herbs. She doesn't want 30 check-in notifications at 6:45am Saturday. More importantly, the customer onboarding flow already collects product preferences (FR20e/FR42b) — this feature puts those preferences to work rather than letting them sit unused. The implementation cost is low because the infrastructure exists; the retention cost of NOT doing it grows with every new vendor.

Suggested Next Step

Extend the customer onboarding product preference flow (FR20e/FR42b) to also control notification filtering. Design the notification dispatch filter in the FCM event handler that checks customer category preferences before sending. Wire up a "Notification Preferences" screen in the customer Profile tab.

---

Generated by the weekly feature ideation workflow on 2026-08-07.