Implementation Strategy

Last Updated: March 3, 2026. Status: Active Development Plan.

🎯 Overall Strategy

Phase 1: UI/UX Completion with Mock Data (Current Phase)

• Build all user-facing features with local/mock data
• Focus on user experience, validation, and workflows
• Ensure all screens are functional and polished
• Use local data updates for immediate feedback

Phase 1.5: Local Storage (Intermediate)

• Persist mock data on device so it survives app restarts
• Use AsyncStorage (or similar) for products, venues, tools, etc.
• Same data layer and UI; add load/save to device storage
• See Local Storage Options for approach

Phase 2: Backend Integration (Future Phase)

• Comprehensive backend integration in one focused effort
• Replace local/mock data with GraphQL mutations/queries
• Migrate from device storage to persistent database
• End-to-end testing of all features

---

📊 Current Status

✅ Completed Features (3)

1. Product Editing - Full CRUD with local data
2. Shopping List Auto-Generation - Working with mock data
3. Inventory Comparison - Working with mock data

🚧 In Progress (0)

• None currently

⏳ Pending UI Features (18)

See “Coming Soon Features” document for full list

---

🗓️ Phase 1: UI/UX Completion (Current)

Goals

• ✅ Complete all user-facing features
• ✅ Validate user workflows
• ✅ Polish UI/UX
• ✅ Use mock data for rapid iteration
• ✅ Gather user feedback

Approach

1. Mock Data First

   • Use local data stores (@/data/*)
   • Update mock data directly for CRUD operations
   • Changes persist until app reload
   • Fast iteration without backend dependencies

2. Prepare for Backend

   • Structure data updates to match GraphQL schema
   • Use same data shapes as backend will return
   • Keep mutation preparation logic (already done)
   • Comment out GraphQL calls with clear TODOs

3. Benefits

   • ✅ Rapid development
   • ✅ No backend blockers
   • ✅ Easy to test and iterate
   • ✅ User feedback on UX before backend work
   • ✅ Clear understanding of data requirements

Priority Order (High → Low)

🔴 High Priority (Core Features)

1. Restock Functionality - Update product levels
2. Edit Guest - Modify guest information
3. Inventory Item Editing - Edit generic inventory items
4. Recipe Making Mode - Step-by-step recipe guidance

🟡 Medium Priority (Useful Features)

1. Bar Setup Creation - Create bar configurations
2. Edit Bar Setup - Modify bar setups
3. Add Tool/Equipment/Glassware - Inventory management

🟢 Low Priority (Nice to Have)

1. Print Bar Setup Checklist - Export functionality
2. Delete Operations - Product/inventory deletion

---

💾 Phase 1.5: Local Storage (Intermediate)

When to Start

Trigger: When Phase 1 UI features are largely complete and you want data to persist across app restarts without backend dependency.

Goals

• ✅ Data survives app restart (no more losing inventory on reload)
• ✅ Same mock data structures; add persistence layer only
• ✅ Optional: one-time seed from current mock data for new installs
• ✅ No backend or schema changes

Approach

1. Storage abstraction

   • Add a small module (e.g. shaker/infra/localStorage.ts) wrapping AsyncStorage
   • Define keys per domain: INVENTORY_PRODUCTS, VENUES, INVENTORY_TOOLS, etc.
   • Expose getItem<T>(key), setItem(key, value) with JSON serialize/deserialize

2. Data layer

   • On app init: read from AsyncStorage; if empty, seed from current mock data and write back
   • On mutations (add/update/delete): update in-memory state and call setItem so changes persist
   • Keep existing @/data/* APIs; persistence is an implementation detail behind them

3. Scope

   • Products, venues, tools, glassware, equipment, events, menus, budgets (align with shaker/data/)
   • Auth stays in expo-secure-store (Clerk); no change there

Reference

• Local Storage Options for React Native — options, recommendation (AsyncStorage first), and implementation sketch

---

🚀 Phase 2: Backend Integration (Future)

When to Start

Trigger: When Phase 1.5 (local storage) is in place and Phase 1 features are complete and tested

Estimated Timeline: 2-3 days of focused work

Goals

• ✅ Replace all mock data with database
• ✅ Implement all GraphQL mutations
• ✅ Add authentication/authorization
• ✅ Enable multi-device sync
• ✅ Production-ready data persistence

Backend Work Required

Already Implemented ✅

• GraphQL schema for all domains
• Most query resolvers
• Some mutations: createProduct, createRecipe, createEvent
• Database with CQRS/Event Sourcing
• GraphiQL interface

Need to Implement 🔨

1. Product Mutations

   • updateProduct - Update product details
   • deleteProduct - Remove products

2. Inventory Mutations

   • updateInventoryLevel - Already exists, just connect
   • restockProduct - Restock functionality

3. Recipe Mutations

   • updateRecipe - Already exists, just connect
   • deleteRecipe - Remove recipes

4. Event/Guest Mutations

   • updateEvent, deleteEvent
   • createGuest, updateGuest, deleteGuest
   • updateRSVP

5. Venue/Bar Mutations

   • updateVenue, deleteVenue
   • createBarSetup, updateBarSetup

Integration Approach

1. One Domain at a Time

   • Start with Products (most complete)
   • Then Recipes
   • Then Events/Guests
   • Finally Venues/Bars

2. For Each Feature

   • Uncomment GraphQL mutation call
   • Remove local data update
   • Test CRUD operations
   • Verify data persistence
   • Update tests

3. Migration Strategy

   • Migrate from local storage (Phase 1.5) to backend; keep local as offline cache if desired
   • Keep mock data as fallback during transition
   • Gradual rollout per feature
   • Easy rollback if issues arise

---

📋 Next Steps (Immediate)

This Week

1. ✅ Complete product editing (DONE)
2. 🔴 Implement restock functionality with mock data
3. 🔴 Implement edit guest with mock data

Next Week

1. 🟡 Implement bar setup creation with mock data
2. 🟡 Implement inventory item editing with mock data

Following Weeks

• Continue building UI features with mock data
• Gather user feedback
• Refine workflows
• Prepare for backend integration

---

🎯 Success Criteria

Phase 1 Complete When

• ✅ All “Coming Soon” alerts removed
• ✅ All core workflows functional with mock data
• ✅ UI/UX polished and tested
• ✅ User feedback incorporated
• ✅ Clear data requirements documented

Phase 1.5 Complete When

• ✅ All domain data (products, venues, tools, etc.) persisted to device
• ✅ Data survives app restart
• ✅ New installs seed from mock data; returning users load from storage
• ✅ No regression in existing CRUD flows

Phase 2 Complete When

• ✅ All features use real backend
• ✅ Data persists across app restarts
• ✅ Multi-device sync working
• ✅ Authentication implemented
• ✅ Production-ready

---

📝 Notes

• Mock data is temporary but valuable - Allows rapid iteration
• Local storage is an optional middle step - Improves UX (persistence) before backend; simplifies Phase 2 migration from known storage format
• Backend is ready - Infrastructure exists, just needs mutations
• Clear migration path - Mock → Local storage → Backend (or Mock → Backend if skipping 1.5)
• User-focused approach - Get UX right before backend complexity