Inspiration
Most nutrition apps assume one person per plate. Real households don’t work that way — one pot, split by who’s hungrier or who serves themselves first, not by who actually needs what. One number stuck with me while I was reading through RDA tables: a woman eating exactly her fair share of a family meal can still land around 64% of her iron requirement, just because the pot was sized for the household average, not for her specifically. Nobody’s doing anything wrong — the math itself is quietly unfair. I wanted something a family could act on that same night, not a report pointing them to a nutritionist they probably can’t afford.
What it does
You set up your household — who’s eating, their age/sex group (that pulls in the right RDA targets automatically), and how much of the shared pot each person actually eats. You log what’s already being cooked, in grams, at whatever you’re currently paying. PlateFix shows exactly who’s short on what, then solves for the smallest set of changes — add this, increase that — that closes the most gaps for the least extra money per day. Everything recalculates the moment you change a number, so you see the trade-off live instead of waiting for a report. There’s a share link and a direct WhatsApp button, since the plan needs to reach whoever’s actually cooking, not just sit on one phone.
How we built it
The core is a linear program — javascript-lp-solver running the simplex method client-side, so there’s no backend and no server cost, which mattered a lot on this timeline. The harder part wasn’t the solver, it was the data: I built the food list by hand, about 25–30 items people here actually cook with, each with real nutrient values and a price per kilo, Hindi name next to the English one because that’s genuinely how these foods get talked about at home. I tested it against three different household setups before trusting the output. I used Claude throughout as a coding partner — I’m not an experienced engineer, so a lot of the TypeScript structure and solver wiring came out of that back-and-forth, but the nutrition logic, the food data, and the decision to frame this as “smallest change” instead of “new meal plan” were mine.
Challenges we ran into
Getting the solver to suggest something a real family would actually do was harder than getting it to solve at all. Early versions proposed things like 400 extra grams of one obscure leafy green because that was mathematically optimal — useless if nobody’s buying that much of something they don’t normally cook. I had to push it toward small, realistic increases spread across familiar foods instead of one large weird one. Sourcing decent nutrient-per-rupee data for regional foods was slower than expected too — most nutrition databases are built around Western ingredients, so a chunk of this came from cross-checking multiple sources by hand.
Accomplishments that we’re proud of
The thing I’m most proud of is the “average hides someone” view — watching a test household where the overall numbers looked fine, but one member was quietly under 70% on two nutrients, made the whole project feel worth finishing. I’m also proud it solves in milliseconds and shows its work (the simplex step count is right there on screen) instead of being a black box, and that it’s built around ₹ budgets and foods people here actually cook, not a Western grocery list with the currency symbol swapped.
What we learned
I learned a lot more about RDA tables and how requirements scale by age and sex than I expected going in — that part was new territory, not just a coding problem. I also learned this exact kind of problem, multi-person nutrient optimization, has real academic and even patent history behind it. Useful gut-check: the math isn’t the new part here. Making it usable for an actual family on an actual budget is.
What’s next for platefix
Right now it’s one day’s pot at a time — the obvious next step is a weekly view, since grocery budgets get planned by the week, not the day. I’d like to add more regional food sets beyond the one I built this around, support more household situations (pregnancy, elderly-specific needs), and eventually pull in live local price data instead of manually edited prices, so the cost side stays accurate without upkeep.
Built With
- claude
- github
- javascript
- javascript-lp-solver
- typescript
- web
Log in or sign up for Devpost to join the conversation.