Exploratory product / AI-assisted cooking
Exploring a smarter way to cook with what you already have
The product question
What if the pantry became the starting point?
What you already have should shape what you cook next.
Product logic
What I have
Food, quantities, storage and expiry.
- Storage location
- Quantity
- Expiry date
What needs attention
Ingredients that should be used soon.
- Expiring soon
- Forgotten items
- Running low
What could I make?
Recipe and meal ideas grounded in what is available.
- Recipe ideas
- Meal planning
- Shopping list
Service journey
Designing the journey before the system
The prototype connected the full KitchenWhizz journey — from understanding preferences and pantry context to creating recipes and cooking them.
01Onboard
02Understand
03Capture
04Decide
05Discover
06Cook
A connected prototype made the complete product journey tangible before every supporting system existed.
Interaction studies
Giving the hardest interactions a shape
KitchenWhizz became most interesting where household context could change a decision: capturing food, choosing what to cook, and moving from an idea into action.
Select a study to explore
Capture without friction
A receipt becomes reviewable pantry items without manual entry.
Receipt-to-review interaction study for reducing pantry upkeep.
Functional prototype
The pantry became the working foundation
The pantry became the first working slice of KitchenWhizz, turning household context into persistent product data that could be captured, updated, and used over time.
Designed interaction
Working implementation
My Pantry
The working pantry connected the mobile experience to persistent household context.
System design
The experience was designed together with the system behind it
KitchenWhizz was never only a set of screens. The journey people move through, the logic behind each decision, the household context it remembers, and the software structure underneath were designed as one system — so the idea could be judged as a product, not a mockup.
Trace a pathThree traces, one loop.
A receipt becomes reviewed items, and the household record grows.
Interface
What a person touches
Capture
Scan a receipt, add an item, correct what was read.
Decide
Choose a meal from options the household can actually make.
Cook
Follow the steps, then confirm what was used.
Logic
How a decision gets made
Recognition
Raw input becomes reviewable pantry items.
Recipe generation
Stock, preferences and constraints resolve into one suggestion.
Guidance
A chosen recipe becomes ordered steps and a use event.
Household model
What the product remembers
Single source of truth
One household model behind every screen
Every layer reads from and writes to the same household record.
Who touches it
- Capturewrites
- Recipe generationreads
- Guidancewrites
What it holds
Pantry & quantities
itemquantityunit
Storage & expiry
locationopenedbest before
Preferences & diet
likesavoidsallergens
Accounts & history
householdcookedused
Engineering
What holds it up
The structure the model rests on
- 01
Domain entities that own each other
Class architecture
- 02
What each part of the service answers for
Backend responsibilities
- 03
Every record belongs to one household
User-scoped persistence
- 04
One source of copy, four locales
Localization
Open questions
The next experiment had a sharper focus
Once the journey and technical foundation were tangible, the next phase could focus on the behaviors that would determine whether KitchenWhizz deserved deeper investment.
What needs proof
Does household context create enough value to change behavior?
- 01Habit
Make pantry upkeep worth the effort
Reduce capture friction
- 02Decision
Help people decide what to cook
Improve choice quality + speed
- 03Trust
Earn confidence in the guidance
Reliability · allergens · safety
- 04Behavior
Measure what changes at home
Use · discard · inventory events
NextEvidence
The next step was no longer more interface exploration. It was evidence.
Multidisciplinary exploration
Turning a broad idea into a product direction
The value was not the number of screens explored. It was a sharper view of what the product had to become.
- 01Framing
Framing an interconnected problem
Inventory, expiry, meal decisions, cooking, and shopping had to be read as one household journey.
One household journey, not five features
- 02Design
Designing before overbuilding
The service was mapped interactively in Figma, so uncertain workflows could be examined before they were built.
An interactive service prototype
- 03Engineering
Building the deterministic foundation
Accounts, preferences, product data, and pantry persistence gave the concept a real technical base.
A working technical base
- 04Judgement
Separating ambition from evidence
Implemented foundations were held apart from ideas still needing usability, safety, and commercial proof.
A ranked list of what to prove
The takeaway
Build the system, but first prove which system deserves to exist.
TECHNOLOGY
The technology behind KitchenWhizz
The exploration ran on a real technical foundation: a native mobile app with its own accounts, household data, automated checks, and a release pipeline onto real devices.
- FigmaInterface design
- React NativeMobile application
- ExpoRuntime & releases
- TypeScriptShared language
- React Native PaperInterface components
- SupabaseBackend & data
- PostgreSQLHousehold data
- DenoEdge functions
- DockerLocal environment
- GoogleAccount sign-in
- AppleAccount sign-in
- i18nextLocalization
- Expo NotificationsExpiry alerts
- JestAutomated tests
- GitHubSource control
- GitHub ActionsCI/CD automation
Product & technical consulting
Exploring a product idea before committing to the build?
Synertech Labs can help frame the problem, identify the highest-risk assumptions, prototype the experience, and build the technical foundation — either directly or in collaboration with your team.