The problem
The organising idea is leftover-ingredient search: the primary way in is not browsing recipes but asking what can be made from what is already in the kitchen. That shaped the data model - free-text matching across titles and ingredients, category filtering through a Firestore arrayContains query, and a servings threshold, composed as one multi-filter search rather than a list to scroll.
What I built
- Implemented email/password authentication and session handling with Firebase Authentication, plus a profile module with gallery image selection and upload to Firebase Storage, persisting the download URL to the user document.
- Designed a Cloud Firestore model spanning recipes, categories, per-user favourites and per-user shopping lists, driving the UI with real-time StreamBuilder listeners so changes propagate without manual refresh.
- Built a shopping list with atomic Firestore arrayUnion/arrayRemove writes, letting users add items from a recipe detail screen or manage them independently.
- Managed favourites state with the Provider pattern via a ChangeNotifier store that hydrates from Firestore on launch and keeps an in-memory list for constant-time lookups.
- Implemented a tabbed recipe detail screen presenting ingredients and directions alongside servings, preparation time and difficulty, with responsive layouts across mobile, tablet and desktop breakpoints.
Stack
FlutterDartFirebase AuthenticationCloud FirestoreFirebase StorageProviderimage_pickerGoogle FontsMaterial Design
Skills applied
- Cross-platform mobile development
- NoSQL data modelling
- Real-time data synchronisation
- State management architecture
- Authentication and session handling
- Cloud file storage
- Responsive and adaptive UI design
- Search and filtering logic