PantryPal: A Private, Offline Kitchen Assistant Built for My Friend

Ayush Kumar — Sun, 04 Oct 2026 10:35:35 +0000

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

Video

Code

PantryPal GitHub repository

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.

CSS :has() Is the Parent Selector We Waited 20 Years For

Ayush Kumar — Sat, 03 Oct 2026 18:20:38 +0000

For years, the answer to "can CSS select a parent based on its children?" was a sad "no, use JavaScript."

Not anymore. :has() is supported in all modern browsers, and it changes how you write CSS. Here are three tricks you can use today.

1. Style a card differently if it contains an image

.card {
  display: grid;
  gap: 1rem;
}

.card:has(img) {
  grid-template-columns: 200px 1fr;
}

No extra classes like .card--with-image. The CSS looks at the content and adapts.

2. Highlight a label when its input is invalid

label:has(+ input:invalid) {
  color: crimson;
}

The label turns red when the input right after it fails validation. No JS, no state.

3. A dark mode toggle with zero JavaScript

<input type="checkbox" id="theme" />
<label for="theme">Dark mode</label>

:root {
  --bg: #fff;
  --fg: #111;
}

:root:has(#theme:checked) {
  --bg: #111;
  --fg: #eee;
}

body {
  background: var(--bg);
  color: var(--fg);
}

The checkbox lives anywhere in the page, and :root reacts to it.

Bonus: it works like a "not" too

/* Dim all siblings when one is hovered */
ul:has(li:hover) li:not(:hover) {
  opacity: 0.5;
}

Wrap up

:has() lets CSS respond to the content and state of your markup, and that cuts a lot of "toggle a class" JavaScript.

What's the coolest thing you've built with it? Let me know in the comments

DEV Community: Ayush Kumar