Meal Rescue

Inspiration

The idea for Meal Rescue started with a simple question from the Abbey’s Kitchen challenge: what can we add to make a meal more satisfying?

That question made me think about how people actually eat in everyday life. We often have food already available, but the meal does not always feel complete. Maybe it is missing something, maybe the combination is not quite right, or maybe it simply does not match what we are craving at that moment.

That led to a different way of thinking about meals. Instead of always replacing a meal with a new recipe, what if we could improve the meal we already have?

That became the inspiration for Meal Rescue: help people turn an almost-right meal into a meal they actually enjoy.


What it does

Meal Rescue is a personalized meal companion that helps you make better decisions with the meal you already have.

It learns your taste from the moment you start the app for the first time and improves suggestion more better over time like —what you enjoy, what you avoid, and what combinations work for you—so its suggestions become increasingly personal rather than generic.

It is also built for real households. When different people want different things, Meal Rescue helps adapt meals to individual preferences so you do not have to cook completely separate dishes for everyone.

And when life gets busy, Meal Rescue helps you plan around your day. It can work with what is already in your kitchen, help you make use of leftovers and ingredients before they go to waste, and guide you toward what to prepare, add, or buy next.

“Given what I have, who I am cooking for, and what my day looks like, what should I do with this meal?”


How we built it

We built Meal Rescue as a context-aware mobile application, with the goal of making personalization a core part of the product rather than adding it as a layer on top of a generic AI experience.

The app was built with React Native and Expo, with Supabase supporting the application's backend services and RevenueCat powering subscriptions and premium entitlements with OneSignal powered Notification system. This gave us a single mobile product while keeping user data, personalization, and monetization connected to the experience.

Taste Memory

The most important system we built was Taste Memory. Rather than treating a person’s preferences as a fixed list of likes and dislikes, Meal Rescue keeps track of how their preferences change across contexts. Each learned preference is associated with a context and updated with both an affinity and a confidence value. This allows the system to learn progressively from actual decisions and feedback instead of letting one interaction define a user's entire taste profile.

Context-Aware Recommendations

We designed the meal experience around several pieces of context that have to work together. The system can consider the meal itself, the person’s learned preferences, and what is available in their kitchen when producing a recommendation. This was important because a useful suggestion is not simply something that sounds good—it has to make sense for that particular person and their current situation.

Shared Households

We also designed Meal Rescue for shared households, where the people eating the same meal may have different preferences. Individual taste information can therefore remain personal while the meal and kitchen context can still be shared. This allows the product to reason about the people around a meal instead of treating the household as one generic user.

Kitchen and Meal Planning

The same foundation extends into the Kitchen and meal-planning experience, where available ingredients, leftovers, and upcoming meals provide additional context for decisions. Instead of generating isolated meal ideas, the system is designed around the reality of what is already available and what the user is trying to accomplish.

Learning Loop

Finally, we built the experience as a learning loop. A recommendation leads to a decision, the decision can produce feedback, and that feedback can become another signal for future personalization. This means the product is designed to become more relevant through use rather than remaining static after onboarding.

The core product is not simply getting AI to generate suggestions. It was building the surrounding system that allows those suggestions to become personal, contextual, and increasingly useful over time.


Challenges we ran into

1. Turning onboarding into something the system could actually learn from

One of our first challenges was figuring out what to ask during onboarding. We did not want generic questions that simply collected favorite foods; we wanted the onboarding to reveal enough about a person’s preferences to make the first recommendations meaningful. Designing questions that were simple for the user to answer while still producing useful signals for personalization required a lot of iteration.

2. Making Taste Memory evolve without becoming unreliable

Learning someone's taste is not as simple as storing likes and dislikes. People can enjoy the same ingredient in one context and dislike it in another, and a single unusual choice should not permanently change their profile. We therefore had to think carefully about how preferences should be recorded, strengthened, weakened, and given confidence over time so that Taste Memory could evolve gradually from real decisions and feedback.

3. Personalizing one shared meal for different people in cook for the table

Cooking for multiple people introduced another difficult problem: the meal may be shared, but everyone's preferences are not. We had to design the system so that each person's taste could remain distinct while Meal Rescue could still reason about one shared meal, rather than treating the entire household as a single user.

4. Re-scoping the product around what we could actually ship

We initially approached the project through the Abbey’s Kitchen category, where the submission path required a publicly launched app. With the constraints around getting a store release out, we had to rethink the scope and target the Next Gen path instead. That pushed us to focus on building the core Meal Rescue experience and its underlying personalization systems well, rather than spreading our effort across a rushed public launch.


Accomplishments that I'm proud of

  • Turning a notification into part of the product experience - We were not satisfied with the idea of sending another generic “How was your meal?” notification. We made the interaction contextual by connecting the message to the meal the user had actually eaten roughly 30 minutes earlier, turning a normally static notification into a natural continuation of the meal experience and a useful source of feedback for the system.

  • Turning a challenge prompt into a product we genuinely believe in - What started as a simple challenge question became a much broader product idea. We kept pushing beyond the initial interaction until Meal Rescue had a clear identity around understanding the person, the meal, the kitchen, and the context around eating.

  • Becoming an app developer by actually shipping an app - This project also represents a personal milestone for me. Meal Rescue was my first complete app-building experience, and taking it from an idea through product design, interaction design, engineering, personalization, monetization, and a working end-to-end product gave me something more valuable than simply completing a hackathon project: I finally felt that I had crossed the line from someone who wanted to build apps to someone who could actually build one.


What I learned

  • Learning how to choose ideas, not just build them

Before Shipaton, I mostly thought about whether I could build an idea. During this project, I learned that the more important question comes first: is this an idea worth building? I spent around two weeks studying previous Shipaton winners, their products, submissions, demos, and the patterns behind what made them stand out. That changed how I evaluate ideas. I now look at the problem, the user, the uniqueness of the concept, the experience I can create around it, and the story I can tell—not just the technology I can use.

  • Learning that a good UI is not enough

I also learned that a polished interface is more than arranging the right screens and components. Small decisions around animation, transitions, timing, hierarchy, and interaction can completely change how an experience feels. While building Meal Rescue, I became much more intentional about choosing UI elements, animations and giving important interactions the right motion instead of leaving the product as a collection of static screens.

  • Learning to build for an experience, not an MVP checklist

One of the biggest lessons I took away is that simply reaching an MVP is not the end goal. I became much more interested in building something people can actually enjoy using—what is often described as a Minimum Lovable Product or Minimum Awesome Product. That changed the way I approached decisions throughout Meal Rescue: instead of asking only, “Does this feature work?”, I started asking, “Does this make the product feel better?”

  • Learning how product and marketing are connected

Although Meal Rescue has not yet been marketed publicly because it is not available on the App Store or Google Play, I learned that marketing starts much earlier than promotion. Studying successful products taught me to think about positioning, messaging, the first impression, the product story, and what makes someone care enough to try something. I now understand that building a product and explaining its value are two parts of the same job.

  • Realizing that I can build beyond the classroom

Perhaps the biggest lesson was personal. Before Shipaton, I saw myself primarily as a student who could code and build projects. This experience pushed me to think like a product builder—someone who can choose an idea, shape the experience, make difficult product decisions, build the system behind it, and take it all the way to a working app. For me, that shift is one of the most meaningful things I am taking away from Meal Rescue.


What’s next for Meal Rescue

1. Expand Beyond Our First Market

We want to make Meal Rescue useful across India, the United States, and other markets, adapting the experience to different cuisines, ingredient availability, shopping habits, and household needs rather than designing it around a single food culture.

2. Connect Recommendations to Grocery Shopping

When Meal Rescue recommends an ingredient that is missing from the user's kitchen, the next step is to make that recommendation actionable. We plan to explore affiliate and grocery-commerce integrations with services such as Blinkit, Zepto, and Amazon in India, and Instacart, Walmart, and Amazon Fresh in the US, so users can move from a recommendation to purchasing the missing ingredient with minimal friction.

3. Make Shared Tables Truly Connected

We want multiple people in the same household to be able to connect their Meal Rescue profiles. This would allow the system to understand everyone's individual preferences while still planning and adapting meals for a shared table.

4. Grow Through Real Users

Once launched, we want to focus on user acquisition, retention, and product-led growth. We will use real usage and feedback to understand which experiences create lasting value and where the product needs to improve.

5. Build a Sustainable Business

The long-term goal is to turn Meal Rescue into a sustainable product through thoughtful premium monetization, while keeping the core experience genuinely useful for everyday users.

6. Move Toward Household Food Intelligence

Ultimately, we want Meal Rescue to evolve beyond rescuing individual meals. The vision is a system that understands the people at the table, the food in the kitchen, the meals coming next, and the decisions that connect them all.

A Turning Point for Meal Rescue

While promoting Meal Rescue in WhatsApp communities, Carson Rodrigues, a product engineer with 7 apps live across the App Store and Google Play, replied asking to see the app. After seeing Meal Rescue, he expressed interest in acquiring it for $210. His portfolio of shipped apps is available here.

For a project that began as a student-built hackathon idea, having an experienced app developer see enough potential in Meal Rescue to want to acquire it was a meaningful moment for us.

Explore Meal Rescue

GitHub YouTube Medium X LinkedIn

Meal Rescue

Inspiration

The idea for Meal Rescue started with a simple question from the Abbey’s Kitchen challenge: what can we add to make a meal more satisfying?

That question made me think about how people actually eat in everyday life. We often have food already available, but the meal does not always feel complete. Maybe it is missing something, maybe the combination is not quite right, or maybe it simply does not match what we are craving at that moment.

That led to a different way of thinking about meals. Instead of always replacing a meal with a new recipe, what if we could improve the meal we already have?

That became the inspiration for Meal Rescue: help people turn an almost-right meal into a meal they actually enjoy.


What it does

Meal Rescue is a personalized meal companion that helps you make better decisions with the meal you already have.

It learns your taste from the moment you start the app for the first time and improves suggestion more better over time like —what you enjoy, what you avoid, and what combinations work for you—so its suggestions become increasingly personal rather than generic.

It is also built for real households. When different people want different things, Meal Rescue helps adapt meals to individual preferences so you do not have to cook completely separate dishes for everyone.

And when life gets busy, Meal Rescue helps you plan around your day. It can work with what is already in your kitchen, help you make use of leftovers and ingredients before they go to waste, and guide you toward what to prepare, add, or buy next.

“Given what I have, who I am cooking for, and what my day looks like, what should I do with this meal?”


How we built it

We built Meal Rescue as a context-aware mobile application, with the goal of making personalization a core part of the product rather than adding it as a layer on top of a generic AI experience.

The app was built with React Native and Expo, with Supabase supporting the application's backend services and RevenueCat powering subscriptions and premium entitlements with OneSignal powered Notification system. This gave us a single mobile product while keeping user data, personalization, and monetization connected to the experience.

Taste Memory

The most important system we built was Taste Memory. Rather than treating a person’s preferences as a fixed list of likes and dislikes, Meal Rescue keeps track of how their preferences change across contexts. Each learned preference is associated with a context and updated with both an affinity and a confidence value. This allows the system to learn progressively from actual decisions and feedback instead of letting one interaction define a user's entire taste profile.

Context-Aware Recommendations

We designed the meal experience around several pieces of context that have to work together. The system can consider the meal itself, the person’s learned preferences, and what is available in their kitchen when producing a recommendation. This was important because a useful suggestion is not simply something that sounds good—it has to make sense for that particular person and their current situation.

Shared Households

We also designed Meal Rescue for shared households, where the people eating the same meal may have different preferences. Individual taste information can therefore remain personal while the meal and kitchen context can still be shared. This allows the product to reason about the people around a meal instead of treating the household as one generic user.

Kitchen and Meal Planning

The same foundation extends into the Kitchen and meal-planning experience, where available ingredients, leftovers, and upcoming meals provide additional context for decisions. Instead of generating isolated meal ideas, the system is designed around the reality of what is already available and what the user is trying to accomplish.

Learning Loop

Finally, we built the experience as a learning loop. A recommendation leads to a decision, the decision can produce feedback, and that feedback can become another signal for future personalization. This means the product is designed to become more relevant through use rather than remaining static after onboarding.

The core product is not simply getting AI to generate suggestions. It was building the surrounding system that allows those suggestions to become personal, contextual, and increasingly useful over time.


Challenges we ran into

1. Turning onboarding into something the system could actually learn from

One of our first challenges was figuring out what to ask during onboarding. We did not want generic questions that simply collected favorite foods; we wanted the onboarding to reveal enough about a person’s preferences to make the first recommendations meaningful. Designing questions that were simple for the user to answer while still producing useful signals for personalization required a lot of iteration.

2. Making Taste Memory evolve without becoming unreliable

Learning someone's taste is not as simple as storing likes and dislikes. People can enjoy the same ingredient in one context and dislike it in another, and a single unusual choice should not permanently change their profile. We therefore had to think carefully about how preferences should be recorded, strengthened, weakened, and given confidence over time so that Taste Memory could evolve gradually from real decisions and feedback.

3. Personalizing one shared meal for different people in cook for the table

Cooking for multiple people introduced another difficult problem: the meal may be shared, but everyone's preferences are not. We had to design the system so that each person's taste could remain distinct while Meal Rescue could still reason about one shared meal, rather than treating the entire household as a single user.

4. Re-scoping the product around what we could actually ship

We initially approached the project through the Abbey’s Kitchen category, where the submission path required a publicly launched app. With the constraints around getting a store release out, we had to rethink the scope and target the Next Gen path instead. That pushed us to focus on building the core Meal Rescue experience and its underlying personalization systems well, rather than spreading our effort across a rushed public launch.


Accomplishments that I'm proud of

  • Turning a notification into part of the product experience - We were not satisfied with the idea of sending another generic “How was your meal?” notification. We made the interaction contextual by connecting the message to the meal the user had actually eaten roughly 30 minutes earlier, turning a normally static notification into a natural continuation of the meal experience and a useful source of feedback for the system.

  • Turning a challenge prompt into a product we genuinely believe in - What started as a simple challenge question became a much broader product idea. We kept pushing beyond the initial interaction until Meal Rescue had a clear identity around understanding the person, the meal, the kitchen, and the context around eating.

  • Becoming an app developer by actually shipping an app - This project also represents a personal milestone for me. Meal Rescue was my first complete app-building experience, and taking it from an idea through product design, interaction design, engineering, personalization, monetization, and a working end-to-end product gave me something more valuable than simply completing a hackathon project: I finally felt that I had crossed the line from someone who wanted to build apps to someone who could actually build one.


What I learned

  • Learning how to choose ideas, not just build them

Before Shipaton, I mostly thought about whether I could build an idea. During this project, I learned that the more important question comes first: is this an idea worth building? I spent around two weeks studying previous Shipaton winners, their products, submissions, demos, and the patterns behind what made them stand out. That changed how I evaluate ideas. I now look at the problem, the user, the uniqueness of the concept, the experience I can create around it, and the story I can tell—not just the technology I can use.

  • Learning that a good UI is not enough

I also learned that a polished interface is more than arranging the right screens and components. Small decisions around animation, transitions, timing, hierarchy, and interaction can completely change how an experience feels. While building Meal Rescue, I became much more intentional about choosing UI elements, animations and giving important interactions the right motion instead of leaving the product as a collection of static screens.

  • Learning to build for an experience, not an MVP checklist

One of the biggest lessons I took away is that simply reaching an MVP is not the end goal. I became much more interested in building something people can actually enjoy using—what is often described as a Minimum Lovable Product or Minimum Awesome Product. That changed the way I approached decisions throughout Meal Rescue: instead of asking only, “Does this feature work?”, I started asking, “Does this make the product feel better?”

  • Learning how product and marketing are connected

Although Meal Rescue has not yet been marketed publicly because it is not available on the App Store or Google Play, I learned that marketing starts much earlier than promotion. Studying successful products taught me to think about positioning, messaging, the first impression, the product story, and what makes someone care enough to try something. I now understand that building a product and explaining its value are two parts of the same job.

  • Realizing that I can build beyond the classroom

Perhaps the biggest lesson was personal. Before Shipaton, I saw myself primarily as a student who could code and build projects. This experience pushed me to think like a product builder—someone who can choose an idea, shape the experience, make difficult product decisions, build the system behind it, and take it all the way to a working app. For me, that shift is one of the most meaningful things I am taking away from Meal Rescue.


What’s next for Meal Rescue

1. Expand Beyond Our First Market

We want to make Meal Rescue useful across India, the United States, and other markets, adapting the experience to different cuisines, ingredient availability, shopping habits, and household needs rather than designing it around a single food culture.

2. Connect Recommendations to Grocery Shopping

When Meal Rescue recommends an ingredient that is missing from the user's kitchen, the next step is to make that recommendation actionable. We plan to explore affiliate and grocery-commerce integrations with services such as Blinkit, Zepto, and Amazon in India, and Instacart, Walmart, and Amazon Fresh in the US, so users can move from a recommendation to purchasing the missing ingredient with minimal friction.

3. Make Shared Tables Truly Connected

We want multiple people in the same household to be able to connect their Meal Rescue profiles. This would allow the system to understand everyone's individual preferences while still planning and adapting meals for a shared table.

4. Grow Through Real Users

Once launched, we want to focus on user acquisition, retention, and product-led growth. We will use real usage and feedback to understand which experiences create lasting value and where the product needs to improve.

5. Build a Sustainable Business

The long-term goal is to turn Meal Rescue into a sustainable product through thoughtful premium monetization, while keeping the core experience genuinely useful for everyday users.

6. Move Toward Household Food Intelligence

Ultimately, we want Meal Rescue to evolve beyond rescuing individual meals. The vision is a system that understands the people at the table, the food in the kitchen, the meals coming next, and the decisions that connect them all.

A Turning Point for Meal Rescue

While promoting Meal Rescue in WhatsApp communities, Carson Rodrigues, a product engineer with 7 apps live across the App Store and Google Play, replied asking to see the app. After seeing Meal Rescue, he expressed interest in acquiring it for $210. His portfolio of shipped apps is available here.

For a project that began as a student-built hackathon idea, having an experienced app developer see enough potential in Meal Rescue to want to acquire it was a meaningful moment for us.

Explore Meal Rescue

GitHub YouTube Medium X LinkedIn

Built With

Share this project:

Updates

Submission history