Inspiration

We noticed that people who are trying to eat healthy and stay active are juggling two completely separate problems at the same time. They open their fridge, have no idea what to cook, and either order out or throw something together that does not match their goals. Then they look up a workout, and it has nothing to do with what they are eating or what equipment they actually own. We thought those two problems should have one solution, so we built it.

What it does

You take a photo of your fridge, answer a few questions about yourself like your fitness goal, dietary restrictions, available equipment, and weekly grocery budget, and FridgeToFit generates a full week for you. The left side of the screen shows your meal plan: 7 days, 3 meals a day, built from what is in your fridge, staying under your budget, and hitting your calorie targets. The right side shows your workout plan: 7 days tailored to your goal and whatever equipment you have, whether that is dumbbells, a full gym, or just your bodyweight. You can swap any meal you do not want to cook, mark leftovers so they get removed from your grocery list, and check your macro breakdown for the whole week.

How we built it

We split into four work streams and wrote a shared schema and routes document before anyone wrote a single line of code. That decision kept field names consistent across the frontend, backend, and AI layer without constant back-and-forth between teammates. The frontend is built in React with Zustand for state management. It has a split-screen layout with a photo upload flow, a profile form, a meal plan panel with swap and leftover controls, and a workout panel with a loading state to handle AI response time. The backend runs on Node and Express with SQLite via better-sqlite3, covering twelve REST endpoints for users, ingredients, recipes, meal plans, workout plans, and grocery lists. The AI pipeline is five functions in a single file. Gemini 2.0 Flash handles ingredient extraction from the fridge photo. Mistral-7B-Instruct handles meal plan generation, meal swapping, plan summarization, and workout generation, all routed through OpenRouter. Ingredient nutrition data comes from USDA FoodData Central, and calorie targets are calculated using the Mifflin-St Jeor formula.

Challenges we ran into

Mistral was the source of most of our problems. It ignored dietary flags, returned recipe IDs that did not exist, and regularly sent back broken JSON. We fixed this through several rounds of iteration: filtering the recipe pool before it reached the model, embedding the exact list of valid IDs in the prompt, and building retry logic that re-prompts when output fails to parse. Gemini added another problem since it does not support a system role, which broke our original setup and forced us to restructure how we passed instructions to it. On the team side, merging four parallel branches is always a risk, but writing out the schema and API routes as shared documents before anyone started coding kept integration from becoming a problem.

Accomplishments that we're proud of

Every test we ran against the meal plan came back clean. All five profiles, including vegan, halal, gluten-free, bulking athlete, and budget student, passed dietary compliance checks with no made-up recipes slipping through. The workout side held up just as well: bodyweight-only configs had zero dumbbell or barbell movements, and full gym configs correctly included compound barbell lifts. We are also proud of how the AI pipeline turned out structurally. Five functions, one file, shared retry logic, and any one of us can open it and understand what is happening. The full flow from fridge photo to a complete split-screen plan runs in under 20 seconds, which exceeded what we were expecting from free-tier models.

What we learned

This project pushed us into parts of the stack that most tutorials skip over. Prompt engineering for structured output, building retry logic, handling model quirks across different providers, and designing a multi-person backend without stepping on each other all required figuring things out as we went. We came out with a much clearer picture of how to work with language models in a real application context, not just call an API and hope the response is usable. The coordination side taught us something too. Writing contracts before coding is advice that sounds obvious until you actually see how much time it saves when everything needs to come together at once.

What's next for FridgeToFit

There are a few directions we want to take this. Pantry tracking would let the app remember what you have over time instead of starting fresh every session. Connecting the grocery list to something like Instacart would make it possible to order what you are missing without leaving the app. We also want to add actual workout and weight logging so the plan can adjust as you make progress, fix meal swaps to calculate remaining macros properly instead of using fixed estimates, and eventually build a mobile version where taking a photo of your fridge feels completely natural.

Built With

Share this project:

Updates