Nutrimatch

Inspiration

Moving off-campus was a really challenging time for me, and I know it was for others as well. One of the most challenging aspects of the transition was cooking. I had a lot of trouble deciding what to make and how to make as well.

What it does

The project takes in a list of user's preferences/allergies and gives a list of recipes that matches the user's preferences and removes all that contain any allergies. From there, it reads each ingredient and finds it at the nearest Kroger (the only public grocery API) based on the user's inputted zip code. It takes in the quantity of the ingredient and calculates the pricing. After that, each ingredient then gets put into a USDA API call which returns the nutritional information. All this information then gets displayed and there is the option for the user to save it.

How we built it

We started by whiteboarding the core user flow: a user chooses food preferences, a simple algorithm runs and pulls the closest recipes from our recipes database, and we show those recipes to the user for viewing. We then enlisted the help of Claude to write out the scripts and schemas for implementing our whiteboard, verifying its work and making adjustments where necessary to ensure the functionality matches what we visioned. After we had the main functions complete, we added calls to the nutrition and market price APIs for additional user experience, as well as saving recipes and listing the ingredients needed for those recipes in a "grocery list".

Challenges we ran into

A big issue we ran into is the speed of the program. The program is extremely API-dependent. Since we have a set database, we ran the API calls at the start and cache the results in a json file. Now, there's no need for repeated api calls of ingredients, we've looked up before. Another issue is data conversion. A lot of recipes had unclear units. For example, "1 clove of garlic" is a common measurement in recipes. But at a store, a bag of garlic wouldn't say 10 cloves. For these edge cases, we included an error message to inform the user that it's slightly inaccurate and used the full price instead. Another issue is cleaning the recipe data. A lot of the recipes had unclear data, missing units, etc. For these recipes, we filtered them out. In a more polished recipes, there might be some user intervention to properly curate and format these recipes.

What we learned

One thing that we learned a lot about is the sheer volume of high-quality code that Claude and other LLMs are now capable of producing. This means it lies on the developer to ensure all code does what you intend it to, and this can only be done via review and testing the software yourself.

What's next for Nutrimatch

Curating recipes to ensure that allergens and products can be mapped entirely is the highest priority next step. Other than that, adding accounts, sharing/creating/reviewing your and other users' recipes, and automatically determining preferences from previously saved recipes would turn NutriMatch from a simple tool someone can use once on their own in a while to a community-based app that people can use together.

Built With

• alembic
• api
• claude
• fastapi
• python
• react
• sqlite
• typescript