Cold Stone Store
Order Management App — Project Tracker
v1.0 May 2026
Total Sprints
6
Sprint 0 – Sprint 5
Total Duration
9
Weeks total
API Endpoints
12
Auth required on 9
App Screens
16+
Across all flows
Target Users
6
4 primary, 2 secondary
Store Coverage
82
Concurrent sessions
Overall Project Progress
Live — updates as deliverables are checked or statuses change
0%
0%
complete
Deliverable Status Breakdown
Executive Summary

A Flutter-based mobile application for Cold Stone Store personnel enabling real-time order management across all store branches. Staff can view, accept, and track customer orders the moment they arrive — eliminating the current delayed process.

The app integrates with Cold Stone's website via an API provided by the Dash team and is built to handle high-volume concurrent orders across multiple store branches simultaneously.

Platform
Flutter (iOS & Android)
OS Support
Android 8.0+ / iOS 13+
Document
Internal Use Only
Problem Statement
3 issues
Area Current State Target State
Order Acceptance Not acknowledged quickly (static device logic) Accept/reject in under 30 seconds
Visibility No real-time view if out of device or not logged in Live feed with push notifications anywhere
Coordination Manual coordination causing delays between branches Each store manages its own queue independently
Project Timeline
9 weeks total
Week 1
Sprint 0 — Project Setup & Architecture
1 week
Lay technical foundation: Flutter setup, Riverpod, Retrofit, FCM, CI/CD, design system
Week 2
Sprint 1 — Authentication & Onboarding
1 week
Secure staff login, store session init, OTP-based PIN reset
Weeks 3–4
Sprint 2 — Real-Time Order Feed & Acceptance
2 weeks
Core order management: live feed, accept/reject, countdown timers, push notifications
Weeks 5–6
Sprint 3 — Order Tracking & Status Management
1.5 weeks
Full order lifecycle: Pending → Accepted → Preparing → Ready → Completed
Weeks 7–8
Sprint 4 — Order History & Manager Analytics
1.5 weeks
Visibility & reporting: history, manager dashboard, staff activity log
Week 9
Sprint 5 — Polish, Offline Support & Launch
1 week
App Store / Play Store submission: offline mode, animations, accessibility, profiling
Target Users
Primary Users
Primary
Store Officers
Accept or reject incoming orders in real time
Primary
Dispatch Riders
Deliver orders and complete the order lifecycle
Primary
Kitchen Staff
View order details and preparation instructions
Primary
Store Managers
Monitor order flow and staff activity across the store
Secondary
Regional Supervisors & HQ
Aggregated performance across stores, system config, onboarding
Order Status Flow
Sprint 3 implementation
Pending
Accepted
Preparing
Ready
Completed
Rejected (terminal — with required reason)
Non-Functional Requirements
App launch time< 2 seconds on mid-range Android
Order notification delivery< 5 seconds from order placement
API response time< 1 second for all order actions
Offline toleranceCached data usable for up to 10 minutes without connectivity
Session timeoutAuto logout after 8 hours of inactivity
SecurityJWT token encrypted in secure storage; no sensitive data in logs
Supported OSAndroid 8.0+ and iOS 13+
Store coverage82 concurrent store sessions without degradation
Sprint Plan
Click any sprint to expand deliverables and acceptance criteria
S0
Project Setup & Architecture
1 week — Week 1 — Goal: Lay technical foundation
Not started
Deliverables
  • Initialise Flutter project with folder structure (features/, core/, shared/)
  • Configure Riverpod, Retrofit, Dio with base URL and interceptors
  • Set up environment configs: dev, staging, production
  • Implement JWT token storage with secure_storage
  • Define API service interfaces (OrderService, AuthService, StoreService)
  • Set up CI/CD pipeline (GitHub Actions or Codemagic)
  • Configure push notification service (Firebase FCM)
  • Create design system: colours, typography, spacing constants
Acceptance Criteria
  • App boots to splash screen on both iOS and Android
  • All environment configs switch without code changes
  • FCM token is registered and device receives a test push
S1
Authentication & Onboarding
1 week — Week 2 — Goal: Secure staff login & store session init
Not started
User Stories
  • As a store attendant, I want to log in with my Staff ID and PIN so I can access my store's order queue
  • As staff assigned to multiple stores, I want to select which store I'm working at today
  • As a user who forgot my PIN, I want to reset it via an OTP sent to my registered phone number
Screens to Build
ScreenKey ElementsAPI Endpoint
Splash ScreenLogo, loading indicator, auto-login if token validGET /auth/validate-token
Login ScreenStaff ID field, PIN field, Login button, Forgot PIN linkPOST /auth/login
Store SelectionList of assigned stores, Select buttonGET /staff/stores
Forgot PINPhone input, OTP input, New PIN fieldsPOST /auth/request-otp
POST /auth/reset-pin
Acceptance Criteria
  • Login succeeds with valid credentials; JWT stored securely
  • Invalid credentials show a clear error message
  • Auto-login works on app relaunch if token is still valid
  • Store selection persists for the session
  • PIN reset flow completes end-to-end with OTP verification
S2
Real-Time Order Feed & Acceptance
2 weeks — Weeks 3–4 — Goal: Core order management
Not started
User Stories
  • As a store attendant, I want to see incoming orders instantly so I can act on them immediately
  • As a store attendant, I want to accept an order with one tap so customers are notified quickly
  • As a store attendant, I want to reject an order with a reason so the customer and system are informed
  • As a staff member, I want to see a countdown timer on each order so I know how urgently to act
Screens to Build
ScreenKey ElementsAPI Endpoint
Home / Order FeedLive order cards, pull-to-refresh, push notification triggerGET /orders/live (WebSocket/polling)
Order DetailFull item list, instructions, customer note, Accept/Reject buttonsGET /orders/{id}
Accept ConfirmationSuccess animation (Lottie), order status updatePOST /orders/{id}/accept
Reject FlowReason picker (out of stock, store closed, etc.), confirmPOST /orders/{id}/reject
Order Card Design Spec
Order ID & timestamp Customer name Item summary (e.g. '3 items — ₦4,500') Quick Accept button
Timer colours: 🔴 Red if >2 mins waiting  |  🟠 Orange 1–2 mins  |  🟢 Green <1 min
Acceptance Criteria
  • New orders appear on the feed within 5 seconds of being placed
  • Accepting an order updates status to 'Accepted' in real time
  • Rejection reason is required and logged
  • Push notification fires when new order arrives (even if app is backgrounded)
  • Order timer increments correctly and changes colour at thresholds
S3
Order Tracking & Status Management
1.5 weeks — Weeks 5–6 — Goal: Full order lifecycle management
Not started
User Stories
  • As kitchen staff, I want to mark an order as 'Preparing' so the attendant knows it's being worked on
  • As a store attendant, I want to mark an order as 'Ready' so the delivery/pickup team is notified
  • As a manager, I want to see all active orders and their current status at a glance
Order Status Transitions
StatusTriggered ByNext Status
PendingCustomer places order on platformAccepted or Rejected
AcceptedStore attendant taps AcceptPreparing
PreparingKitchen staff taps Start PreparingReady
ReadyKitchen staff taps Mark ReadyCompleted or Picked Up
CompletedSystem or attendant confirms pickup/delivery—
RejectedStore attendant rejects with reason—
Acceptance Criteria
  • Status transitions are instant and reflected across all staff on the same store
  • Completed orders move to history automatically
  • Manager view shows all active statuses without needing to refresh
S4
Order History & Manager Analytics
1.5 weeks — Weeks 7–8 — Goal: Visibility & reporting
Not started
User Stories
  • As a store attendant, I want to review past orders to resolve customer complaints
  • As a manager, I want to see today's order stats so I can track performance
  • As a regional supervisor, I want to compare performance across stores
Screens to Build
ScreenKey Elements
Order HistoryDate filter, status filter, search by order ID, paginated list (20 per page)
Manager DashboardTotal orders today, acceptance rate %, avg response time, top items
Staff Activity LogWhich staff accepted/rejected orders, timestamps (manager/supervisor only)
Acceptance Criteria
  • History loads paginated (20 orders per page) with smooth scrolling
  • Dashboard metrics update every 60 seconds
  • Staff log is viewable only by manager/supervisor role
S5
Polish, Offline Support & Production Readiness
1 week — Week 9 — Goal: App Store / Play Store submission
Not started
Tasks
  • Implement offline mode — cache last known order state with Hive
  • Show 'No Connection' banner and queue actions for retry when back online
  • Add Lottie animations for Accept success, Reject, and Empty State screens
  • Full UI polish pass — spacing, loading skeletons, error states
  • Accessibility audit — font scaling, contrast ratios, touch targets
  • Performance profiling — jank, memory leaks, API timeout handling
  • App icon and splash screen for iOS and Android
  • Build and submit to Google Play Store (internal testing track)
  • Build and submit to Apple TestFlight
Acceptance Criteria
  • App launches in under 2 seconds on mid-range Android device
  • All error states have user-friendly messages (no raw API errors shown)
  • App passes accessibility audit with no critical failures
  • Both iOS and Android builds pass store review requirements
Application Screens Overview
All screens across 6 functional areas
4.1 Authentication
Sprint 1
Splash Screen
Login Screen
Store Selection
Forgot PIN / OTP
4.2 Home / Dashboard
Sprint 2
Live Order Feed
Order Counter Badge
Store Status Toggle
Notification Bell
Store Status Toggle — manager only
4.3 Order Management
Sprint 2 & 3
Order Card
Accept Button
Reject + Reason
Order Timer
Status Flow
4.4 Order History
Sprint 4
Date Range Filter
Status Filter
Search by ID/Name
Export (later sprint)
4.5 Manager Dashboard
Sprint 4 — Role-gated
Order Volume
Acceptance Rate
Staff Activity Log
Store Metrics
4.6 Settings & Profile
Sprint 1 & 5
Staff Profile
Notification Prefs
App Version
Logout
API Integration Specification
12 endpoints — confirmed once API docs received from Dash team
Note: WebSocket endpoint for live order feed to be agreed with backend team. Alternative is polling every 5 seconds if WebSocket is not available in v1.
Method Endpoint Description Auth
POST/auth/loginStaff login with credentials—
GET/auth/validate-tokenCheck if JWT token is still valid
POST/auth/request-otpRequest OTP for PIN reset—
POST/auth/reset-pinReset PIN using OTP—
GET/staff/storesGet list of stores assigned to staff
GET/orders/liveFetch real-time active orders for store
GET/orders/{id}Get full order details
POST/orders/{id}/acceptAccept an order
POST/orders/{id}/rejectReject an order with reason
PUT/orders/{id}/statusUpdate order status (preparing, ready, etc.)
GET/orders/historyPaginated order history with filters
GET/analytics/store/{id}Manager analytics for a store
GET Endpoints
6
Read operations
POST Endpoints
5
Create/action operations
PUT Endpoints
1
Update operations
Auth Required
9
JWT protected
Roles & Permissions Matrix
Feature access by user role
Feature Attendant Kitchen Staff Store Manager Supervisor
View live order feed
Accept / Reject orders
Update order status
View order history
View manager dashboard
View staff activity log
Toggle store open/closed
View multi-store analytics
Attendant
Core order operations: view, accept/reject, update status, view history
Kitchen Staff
Order view, status updates (preparing/ready), history — no accept/reject
Store Manager
Full store control: all ops + dashboard, staff log, store toggle
Supervisor
Read-only across stores: history, dashboards, multi-store analytics
Risks & Mitigations
4 identified risks across the project
API specs delayed beyond tomorrow
Likelihood: Medium Impact: High
Mitigation: Begin UI and mock data development in parallel; wire API when ready
Connectivity issues at store locations
Likelihood: High Impact: Medium
Mitigation: Implement offline mode with local caching in Sprint 5 (Hive-based cache)
Push notifications not firing on some Android OEMs
Likelihood: Medium Impact: High
Mitigation: Test on Tecno, Infinix, Samsung devices popular in Nigeria; use FCM high-priority flag
Backend API performance under 82 concurrent stores
Likelihood: Medium Impact: High
Mitigation: Agree on load test requirements with backend team before Sprint 2 begins
Risk Summary
High Impact Medium Impact
Risk overview: API delay — medium likelihood, high impact. Connectivity — high likelihood, medium impact. Push notifications — medium likelihood, high impact. Backend load — medium likelihood, high impact.