MealMosaic

Inspiration

The inspiration for MealMosaic came from a problem we regularly experienced ourselves. We would have ingredients and leftovers available at home, but we would still struggle to think of something new or enjoyable to make or eat, since we didn't want to be stuck eating the same things over and over. The easiest option was often to eat the same leftovers again, repeat a familiar meal, or order something instead.

So as a result, we thought it would be useful to have a cooking companion that could look at what was actually available within your kitchen and help turn it into a new meal. Instead of treating leftovers as something that can only be reheated, MealMosaic treats them as ingredients that can become part of something new.

Our ultimate goal was to create an experience that could answer a simple question: “What can I make right now with what I already have?” So we aimed to come up with a solution that accounted for exact quantities, dietary preferences, nutrition goals, expiration dates, and meals the user had recently eaten.

Features and Functionality

MealMosaic gives each user a private kitchen where they can keep track of the ingredients, liquids, staples, packaged foods, and leftovers they already have. Inventory items include quantities, storage locations, and entered expiration dates, which gives the recommendation system a more accurate picture of what the user can actually make.

Users can also set dietary exclusions, disliked ingredients, serving size, cooking time, and optional calorie or protein targets. The Today and History views help users track meals they have eaten, including meals logged outside the app, so recommendations can account for both daily nutrition and recent repetition.

When a user is ready to cook, they can ask for a particular meal type, cuisine, mood, or cooking technique, or choose Surprise Me. MealMosaic presents validated suggestions in a swipeable experience, explains why each meal fits, and provides the complete ingredients and cooking instructions. After the user confirms that they cooked a meal, the app records it in their history and updates the affected inventory quantities.

What We Learned

Before this project, while our team had experience working with AI coding assistants before, our team had limited experience using the Codex app. So it was rather interesting to learn how much of the development process we could manage from one place, including things like PRs, as we, for the most part, had been used to using the CLIs for most of these coding assistants.

For this particular project, we had used Codex to create and coordinate multiple tasks, worktrees, and chat threads. The available plugins and skills were also helpful when debugging problems, reviewing our implementation, working with GitHub, and managing our Devpost submission.

Concerning our project, one of our biggest technical lessons came from building the recommendation system. Our first approach relied heavily on recipe templates and blueprints. While that kept the results predictable, it was also too restrictive and repeatedly produced similar meals.

We eventually realized that the GPT model we were using needed more freedom to create meals beyond the predefined blueprints, while still being bounded by the ingredients the user actually had. So we tried to strike the right balance between creativity and reliability, which ultimately took a lot of trial and error. Additionally, it took a lot of trial and error to ground the responses from the model. Even when a response follows the correct format, we still needed to validate the ingredients, quantities, dietary restrictions, expiration dates, nutrition limits, and similarity to previous meals before showing it to the user.

How We Built Our Project

Tech Stack

React Native, Expo, and TypeScript
Python and FastAPI
Supabase Auth and PostgreSQL
SQLAlchemy and Alembic
TanStack Query
Render
USDA FoodData Central and Open Food Facts for food reference data

We began by using the Devpost plugin inside Codex to develop the original idea further. From there, we used Codex to create a product requirements document, technical specification, and build checklist. We then divided the planned features from the checklist amongst the various members of our team and had Codex turn those assigned tasks into GitHub issues.

From there, we built the app in vertical slices. We first connected Supabase authentication and each user’s private kitchen to the FastAPI backend, then added inventory management, daily nutrition goals, meal logging, and history before building the recommendation and cooking flows. The mobile experience was built with Expo and React Native, while the backend handled authenticated data access, recommendation sessions, OpenAI requests, validation, and inventory transactions. As each slice was completed, we integrated the changes through reviewed pull requests and tested the complete flow in the iOS Simulator against both the local and deployed API. This allowed us to verify the experience from signing in and adding ingredients to generating a recipe, confirming the meal, and seeing the inventory, Today view, and meal history update afterward.

How the Recommendation System Works

The recommendation process begins with a snapshot of the user’s current kitchen. This includes their available ingredients, exact quantities, storage locations, expiration dates, dietary preferences, serving size, cooking time, nutrition targets, recent meals, and previously dismissed recommendations.

We then use that information to determine which ingredients and combinations are feasible. GPT-5.6 Luna can then create and adapt a wider variety of meals instead of being limited to a small collection of recipe blueprints. However, the user’s inventory remains the complete ingredient boundary, so the model is not allowed to assume that an unavailable ingredient exists.

Every generated recipe goes through deterministic validation before it reaches the mobile app. The backend verifies that the recipe:

Uses ingredients that are actually in the user’s inventory
Does not use more than the available quantity
Excludes expired ingredients
Respects dietary restrictions and dislikes
Fits the requested serving size and available cooking time
Respects strict calorie limits when enabled
Is meaningfully different from recently shown or eaten meals
Contains practical instructions that match the listed ingredients

If a response fails validation, the system can make a bounded repair attempt. If it still cannot produce a valid recipe, MealMosaic reports that the generation is unavailable instead of showing a meal the user cannot actually make.

Validated meals are displayed as a swipeable deck. Users can dismiss a meal, choose one to view its complete recipe, or permanently suppress similar recommendations. When the user confirms that they cooked a meal, MealMosaic records it in their history and updates the affected inventory quantities in a single transaction.

Challenges We Faced

Our largest challenge was getting the recommendation system to produce meals that were both creative and realistic. Early versions were too dependent on templates, which limited variety. Giving the model too much freedom created the opposite problem because it could introduce ingredients the user did not have or produce meals that were not practical.

We had to iterate several times to find the right separation of responsibilities. GPT-5.6 handles the creative part of generating and adapting meals, while our backend controls the hard rules around inventory, quantities, dietary restrictions, expiration dates, and duplicate recommendations.

Another challenge was handling model latency and failures without making the mobile app feel broken. Recommendation generation can take time, so we needed a session-based system that could track generation progress, prevent duplicate work, and clearly distinguish between loading, unavailable, and completed states.

We also encountered challenges connecting the Expo application, local FastAPI backend, hosted backend, Supabase authentication, and iOS Simulator. Problems that initially appeared to come from the mobile interface sometimes came from networking, authentication, deployment configuration, or the recommendation worker. Learning to separate and test each part of the system helped us diagnose those issues more efficiently.

Finally, coordinating parallel work across multiple team members and branches required careful organization. Worktrees, focused GitHub issues, automated tests, and code reviews helped us combine the separate mobile, backend, data, and AI work into one complete product.