Case study / Solo product engineer
Provisions.
A pantry-aware meal builder that reduces the effort of deciding what to eat, starting with the ingredients you can use and have available.
Live product · Existing-account flow verified · Signup incomplete
My contribution
Solo product engineer — product logic, interface design, architecture, implementation, and deployment. Visual references drawn from Dribbble and Behance.
Built with
- React
- Notion API
- Auth.js
- Neon DB
- OpenRouter (Gemini 2.5 Flash)
Outcome
Deployed and usable with an existing account. The recommendation, manual selection, substitution, and inventory-review paths were exercised for this case study. I consider the core product functional; sign-up is the known remaining issue. No meal was logged and no stock was changed during the walkthrough.
Visit live product ↗The context
I built Provisions to make eating a little easier for my mum. She could only eat a limited selection of foods and ingredients, so I wanted to help turn the ingredients she could use and already had into meal options that fit her goals. That personal need became a broader idea: make everyday meal decisions take less mental effort, for her, for me, and for other people too.
The problem
Deciding what to eat means reconciling several things at once: what is available, what a person can use, and what makes sense together as a meal. A long list of recipes leaves that work with the user. Provisions starts with a kitchen's ingredient pool and provides a concrete starting point, while allowing the person to change the result.
A useful default, without taking control away
The food-deciding logic, recommendations, and UI had to work toward the same goal: less effort before a person has a meal to consider. The interface offers two paths. Suggest for me produces a starting combination; I'll pick begins with an available base. Both lead to an editable plate. That preserves an escape hatch when the recommendation does not match a person's preference at that moment, rather than making them restart the whole flow.
Evidence / Existing-account walkthrough
What the current build demonstrates
- 01
Sign-in → current kitchen
Signed into an existing account and reviewed its available items, ready-meal area, and meal windows.
- 02
Meal window → suggested plate
Selected Lunch and Suggest for me. The app produced a meal with separately displayed base, protein, and side components.
- 03
Suggestion → personal choice
Opened the available-base picker, then selected an in-stock protein substitution in the draft meal.
- 04
Inventory → visible availability
Inspected kitchen-stock filters, categories, and availability controls. No inventory changes or meal-log writes were made.
A closer look
Tap any image to enlarge and explore the details.
Key features
- A kitchen inventory organized by availability and food category
- Meal-window selection for breakfast, lunch, and dinner
- Automatic suggestions alongside a manual base-selection path
- Independent overrides for a suggested base, protein, and sides
- Saved recipes and a visible ready-meal area
The pantry and recommendation logic
The hardest work was making food recommendations and pantry logic fit together. A suggestion has to reflect the available ingredient pool, while substitutions need to remain understandable. In the live walkthrough, the app offered four lunch bases from the signed-in kitchen, generated a base–protein–side combination, and exposed in-stock protein alternatives. I changed the protein in the draft plate and reviewed the stock controls without editing the pantry. That verifies the interaction path, not the suitability of every possible meal or the correctness of every recommendation rule.
What I would improve next
- Resolve the sign-up flow so new people can reach the working kitchen experience.
- Continue refining recommendation relevance and the clarity of pantry interactions.