💡 Offline-First Market Day Mode

[github-actions[bot]]

Summary

A dedicated "I'm heading to the market" mode that pre-downloads vendor data, market layout, and followed vendors' product catalogs for fully functional offline use. At the market with spotty cell signal, everything just works — vendor statuses, product lists, market info. Background sync attempts happen opportunistically, with clear freshness indicators showing when data was last refreshed.

Market Signal

No farmers market app explicitly markets offline capability for market-day use. The architecture document identifies "outdoor/low-signal environment" as a domain constraint (NFR6 calls for "graceful degradation to polling"). Google Maps' offline mode set the standard for pre-download UX in location-based apps. Market environments — outdoor, crowded, often in rural or semi-rural areas — are exactly the conditions where mobile connectivity degrades. This is a genuine technical differentiator that competitors ignore.

User Signal

The architecture already mandates MMKV for offline cache and optimistic UI for mutations (Apollo Client optimisticResponse). But there's a gap between "the app handles bad connectivity gracefully" and "the app has a deliberate pre-download mode that ensures market-day usability." Market vendors at rural markets frequently report poor cell reception. Rachel checking her phone while walking between stalls needs instant responses, not loading spinners.

Technical Opportunity

MMKV and Apollo Client cache-first policies are already in the technology stack (architecture decision). This feature is about designing the UX around offline-first, not building new infrastructure. The pre-download trigger could be: (1) customer taps "Going to [Market] Saturday" or (2) automatic based on followed markets + proximity + schedule. Apollo's cache-first fetch policy and MMKV's synchronous reads make the offline read path nearly free. Firebase Realtime Database's built-in offline persistence adds another layer.

Assessment

Dimension	Score	Rationale
Feasibility	med	Infrastructure exists (MMKV, Apollo cache, Firebase offline); UX design and pre-download logic are new work
Impact	high	Directly addresses the outdoor-use domain constraint; builds trust through visible reliability
Urgency	med	Should be designed into the architecture from Epic 1, but can be incrementally delivered

Adversarial Review

Strongest objection: The existing architecture already handles offline scenarios via MMKV and Apollo cache. This is just better documentation of existing behavior, not a real feature.

Rebuttal: There's a meaningful UX difference between "the app doesn't crash when offline" and "the app proactively prepares for offline use." The pre-download mode ensures all relevant data (not just recently viewed data) is cached before the customer leaves home. It adds a visible "Downloaded for offline use" indicator that builds trust. And it enables features like offline-capable QR code scanning for vendor check-in verification. The infrastructure exists; the deliberate UX design around it is the feature.

Suggested Next Step

Define an "Offline Market Day Mode" story that spans Epic 6 (customer-side pre-download) and Epic 4 (vendor-side offline check-in). Audit Apollo Client cache policies to ensure all market-day-critical queries use cache-first strategy. Design the pre-download trigger UX.