This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend.
What I Built
I built PantryPal for a friend who lives in a flat, rarely has every ingredient required by a recipe, and wants to follow either a light-oil healthy diet or a high-protein carnivore diet.
PantryPal starts with what my friend actually has:
- their dietary goals
- their available utensils
- their pantry inventory
- their calorie and protein targets
It then recommends recipes that can realistically be cooked in their kitchen.
The app also:
- scales ingredient quantities to the user's targets
- calculates calories, protein, carbohydrates, fat, fiber, vitamins and minerals
- identifies missing ingredients
- suggests substitutions
- rewrites cooking steps for available utensils
- creates a shopping list
- deducts ingredients after a meal is cooked
Demo
Code
The project includes:
- Python and Streamlit UI
- SQLite local storage
- JSON nutrition and recipe data
- deterministic nutrition and portion calculations
- Ollama integration
- unit tests for the core logic
- MIT license
How I Built It
PantryPal uses a hybrid design where deterministic code handles the parts that must be reliable, while the local language model handles the parts where language and taste judgment are useful.
| Layer | Responsibility | Technology |
|---|---|---|
| Code | Filtering, scoring, scaling and nutrition math | Python |
| Local AI | Ingredient substitutions and step rewrites | Qwen3-VL 4B through Ollama |
| Data | Profile, pantry, recipes and nutrition | SQLite and JSON |
| UI | Kitchen assistant interface | Streamlit |
The model does not calculate nutrition or invent arbitrary ingredients.
The code first creates a constrained list of valid substitution candidates. Qwen3-VL then chooses from that list and explains the choice. The result is validated before it is shown to the user.
The nutritional calculations, portion scaling and macro tolerance checks remain deterministic because a small language model should not be trusted with arithmetic.
PantryPal also has a fallback mode. If Ollama is unavailable, the core application still works using code-based recommendations.
Why Does Open Innovation Matter?
Open innovation was important because this app handles highly personal information: body measurements, dietary preferences and pantry contents.
With local inference:
- the user's data stays on their laptop
- the application can work without internet after the model is downloaded
- there are no per-request API costs
- the model can be swapped for another compatible open-weight model
- prompts and validation rules can be changed for one person's needs
- the app remains useful even when the AI engine is offline
A closed hosted API would have made the first version easier to connect, but it would have required sending personal dietary and pantry data to a service my friend does not control.
Using Ollama and Qwen3-VL made privacy and offline operation part of the product instead of an afterthought.
Building for a Friend
I tested PantryPal using my friend's actual kitchen constraints rather than a generic demo profile.
The most important design decisions came from their real situation:
- recipes must work with the utensils they own
- recommendations should begin with ingredients already in the pantry
- missing ingredients should be clearly separated from available ingredients
- portions should match their goals
- the app should not require an account or internet connection
“I liked that it used what I already had instead of giving me another shopping list.”
What I Learned
The most useful architecture decision was keeping the language model away from calculations.
The local model is good at choosing between culinary alternatives and rewriting instructions. Python is better at checking ingredients, calculating nutrition, scaling portions and enforcing constraints.
That separation made the application more predictable while still giving it a natural, helpful interface.
License
PantryPal is released under the MIT License.
Top comments (0)