-
-
Searching interface, including all food venues.
-
Searching interface, including general food venues.
-
Searching interface, including food venues specifically tailored toward food assistance.
-
Mobile view of the weekly meal plan reccomendation.
-
Page for adding a local food giveaway event.
-
Confirmation page once an event has been created by a user.
-
Community event appearing in the search page after being added by a user.
-
Grocery list feature associated with the weekly meal plan reccomendation
-
First part of the user input for getting the weekly meal reccomendation. Includes cusine and dietary preference, location, and weekly budget
-
Second part of the user input for getting the weekly meal reccomendation. Includes nutrition and health information.
-
Example weekly reccomendation
Inspiration
The cost of living in the United States has significantly increased, with this trend showing no sign of relenting anytime soon. Such conditions have given rise to a growing food insecurity crisis. A low income is not the only factor that creates an obstacle to food access. Certain geographic areas (oftentimes coinciding with areas where low-income individuals reside) are considered food deserts, meaning there are few areas where few food options can be found, while others are considered food swamps, meaning while there may have accessible food options, they are not the most nutritious. Food insecurity is associated with a laundry list of negative health outcomes and is indicative of greater socioeconomic hardship. No family nor person should have to suffer through such horrific struggles. Therefore, it is necessary to develop solutions addressing the barriers income and geography create when it comes to food security. Thus, our team decided to develop an application to target just that.
What it does
Our product for this hackathon is an application targeted toward those who face food insecurity. Broadly speaking, there are three main features. Firstly, there are weekly meal recommendations based on the user’s weekly budget, dietary restrictions and goals, cuisines preferences, age, BMI, the number of people they need to feed, and the number of meals per day. Meal data (including ingredients and recipes) was extracted from the open MealDB database, with Grok-powered nutrition estimates of each ingredient and its measurements provided. The recommendation system filters through this information based on the user’s dietary restrictions and cuisine preferences. Then, a K-Nearest-Neighbors (KNN) algorithm ranks meals based on nutritional goals. Each ingredient within a meal is then queried in a Kroger database using the nearest Kroger location to determine the estimated price range. Then, Grok is used to standardize price estimates by serving size, or used directly in cases where the Kroger query fails to return any matches. These corresponding price estimates are attached to each of the ranked KNN outputs. Finally, post-processing is performed by Grok, with output for the user including a weekly meal plan recommendation based on the user’s weekly budget and the remaining information the user provides. Using the rankings from the KNN model, the user can substitute certain meals for other options should they wish. Secondly, there is a filtered search system wherein users can identify venues specifically associated with food assistance initiatives (in addition to general venues) within a radius specified by the user. These venues and their location have been extracted and aggregated from databases maintained by the USDA SNAP Retail Locator, Feed America, and OpenStreetMap. Ideally, by tailoring queries toward nutrition, income, and proximity, those who live in food deserts, food swamps, or otherwise struggle to get proper nutrition can obtain a clearer idea of feasible options. Thirdly, users can host and find events where free food is provided. They are able to specify the location and duration of these events, and they will appear as additional options for food within the aforementioned search feature. Thus, one can learn about the potential food opportunities in their local area, fostering both enhanced food access, communal bonds, and mutual aid networks.
How we built it
Our development process entailed a brief period of brainstorming and ideation. As described in the inspiration section, given the urgency surrounding food insecurity, we chose to focus on this topic. Additionally, we saw this as a potential avenue for innovation for grocery shopping. We researched databases and APIs that had data on different meals, their ingredients, nutritious value, cost, as well as locations offering food assistance resources (in addition to general food vendors). Then, we decided on the three aforementioned features (recommendation algorithm, search feature and event-hosting features). In order for the recommendation algorithm to work, we had to use several different databases and APIs. USDA and MealDB databases were used for gathering nutrition information on meals and ingredients. Meanwhile, Kroger was used to query prices of individual food items. We determined that Grok could effectively standardize these price estimates by serving size and fill in any price information gaps Kroger had. On the other hand, we also considered the broad context of wanting to develop a recommending feature tailored specifically to those facing food insecurity. Thus, we decided to use location, weekly budget, as well as personal health and diet information as a basis for inputs into an algorithm that filters through these databases and ultimately produces a weekly meal plan recommendation tailored to those very needs. We took a similar approach with our search feature: we identified viable APIs, including the USDA SNAP Retailer database, OpenStreetMap, and Feed America, which provided information regarding locations specifically related to food assistance. Then, we combined these into a singular database, and then implemented the search feature in the front-end of our design. In the process of doing so, we ideated our third feature: users hosting their own get-togethers for providing food and community-building. This was primarily a front-end implementation, with provided fields for location, duration, general information, and food items offered for the user to fill out and then add to the existing database.
Challenges we ran into
The biggest challenges we ran into were navigating through different APIs and translating our ideas into a viable programming implementation. Some APIs we had originally desired to use included Edamam and 211 National Data Platform. Our research indicated these databases and their APIs had vast information on meal, food and ingredient options with corresponding nutrition values, as well as location for venues specifically related to food assistance services. However, due to pricing and approval timelines beyond the scope of this hackathon, API keys for these resources could not be obtained. Therefore, we had to handle this challenge by finding alternative databases, which, ultimately, we were able to do successfully, as described by the processes above.
Accomplishments that we're proud of
We are incredibly proud to have been able to persevere through unforeseen barriers to our development process and our ability to adapt accordingly and still make an MVP we find to be viable. Whether it was dealing with API keys, struggling to reason through how to use the databases we obtained, or disagreements surrounding implementation, our sincere desire to create an effective product helping a vulnerable community continually motivated us through these difficulties. Hence, it is this sense of duty and desire that we are most proud of. Additionally, considering that we had limited knowledge, we’re also proud to have learned a lot about how the programming workflow works.
What we learned
On a technical basis, our team, who is on their second hackathon, has become proficient in using git, GitHub, and handling overall version control. Additionally, we learned a lot about the structure, documentation, and usage of APIs as well as cross-communication between databases, since these concepts lied at the heart of what our product was trying to do. We also learned about the high-level differences between TypeScript and Python-based programs and how they support each other as front-end and back-end languages, respectively. We also witnessed first-hand the importance of communication and team consensus for planned workflows. Agreeing on an implementation plan was hard due in part to each of us having different understandings and assumptions of the project workflow and algorithms. We realized this only when actually communicating our respective assumptions about our workflow. Thus, we were able to resolve any misunderstandings and from there make rapid progress, something that we have come to realize would not have been possible without effective communication. For example, we only successfully implemented our recommendation algorithm after clarifying that it would be separate from the searching feature and that proximity would not be considered within the recommendation algorithm.
What's next for Bridge
Current limitations include slow wait times for all user queries, as well as limited information on the hours, services, and items provided by venues for the location-based query feature. Both issues occur on the website as well as during local testing, likely indicating that more data needs to be extracted and implemented into both the back-end and front-end. Additionally, there are minor UI bugs. For example, the zip codes listed in the auto-complete for the searching feature are inaccurate due to database syncing errors. Similarly, the address field for users trying to host an event requires a full address line and has no autocomplete system, making ease of use harder.
In addition to rectifying these limitations, one significant improvement for our application would involve logic to cross-reference ingredients when deciding the meals for the week. This way, the same ingredients can be used over multiple meals rather than having meals that use dissimilar ingredients. This will improve grocery costs and practicality for the user. Similarly, we believe we could connect our app to shopping services such as InstaCart to allow users to directly buy products. Other new features we could add include suggestions for stores to shop at or locations to visit best tailored to user proximity in particular, as well as user finances and dietary. Adding in more social media and gamification features surrounding following certain health goals, hosting events for food giveaways, and even composting and food waste management could be features to potentially implement.
We sincerely believe and hope that our MVP, when refined and up-scaled, could provide a valuable tool that makes getting food for food-insecure individuals seamless and less stressful.
Built With
- api
- chatgpt
- databases
- grok
- python
- sql
- supabase
- typescript
Log in or sign up for Devpost to join the conversation.