• 

  logo

Ripe 🍌

Know before you toss it.

Inspiration

We wanted to be kinder to the planet, and food waste is one of the easiest places to start. Most food thrown out at home isn't dramatic. It's forgotten. A banana slides behind the milk, an avocado sits at the back of the fridge, and by the time we remember them we can't tell if they're still good, so they go in the trash.

We wanted to catch that last-minute "oh no, I forgot about that!" moment and turn it into a meal instead of waste.

What it does

Ripe is a web app. You upload a photo of a fruit or vegetable, and Ripe:

• Identifies the food and scores its freshness from 0 (fresh) to 100 (spoiled)
• Tells you what to do: eat it, cook it, store it, or compost it
• Suggests quick, easy recipe ideas that turn the leftover into a healthy, balanced meal
• Shows your impact in money and CO₂ saved

The score maps to four labels:

$$ \text{label}(s)= \begin{cases} \text{fresh} & 0 \le s \le 30\ \text{use soon} & 31 \le s \le 60\ \text{use now} & 61 \le s \le 85\ \text{compost} & 86 \le s \le 100 \end{cases} $$

Impact is estimated as

$$ \text{CO}_2\ \text{saved} = m \times f $$

where m is the estimated weight of the food rescued (kg) and f is its emissions factor (kg CO₂e per kg of food).

Ripe checks freshness, not foodborne illness.

How we built it

We split the work into a frontend and a backend, and agreed on the JSON format for results before writing any code, so both sides could build at the same time.

Frontend

• React Native with Expo, running as a web app, with Expo Router for the screens
• Photo upload and preview, with image compression before sending
• Loading and error screens, plus a results screen with a color-coded score bar, an action card, tips and impact numbers

Backend

• FastAPI (Python), deployed on Render
• A scan endpoint that sends the photo to the Gemini API, which identifies the food, reads its visual signs and scores its freshness
• An impact endpoint that turns rescued food into CO₂ and money saved, using emissions figures from Our World in Data (Poore & Nemecek, 2018)

We tested every result state with mock data before the backend was ready.

Challenges we ran into

• Mobile app to web app. We started out building a phone app with Expo, but we couldn't get it working reliably in time. We pivoted to a web app, which meant designing the capture flow around photo uploads instead of a live camera. In the end it works in any browser with nothing to install.
• Learning new tools on a deadline. Several of the tools we used were new to us, including Expo, Expo Router, FastAPI and the Gemini API. We had to learn them while building, so we kept the scope small and tested each piece before connecting it to the next.
• Keeping frontend and backend in sync. The two sides were built at the same time, so we had to agree on one shared JSON format and stick to it.
• Four people, one repo. Work was spread across separate branches, and getting everyone's code merged into one working app took careful coordination.
• A scale that runs backwards. Most people expect a high score to be good, but ours treats 0 as perfectly fresh. We designed the score bar to make that obvious.
• A sleeping server. The free hosting plan puts the server to sleep, so the first request is slow. We wake it up before demos.
• Testing every state. The live server returned the same result every time, so we built mock data for each label, action and confidence level.

Accomplishments that we're proud of

• A working end-to-end flow: upload a photo, get a score, an action and your impact, all from a live deployed backend
• A results screen that handles every case: all four labels, all four actions, empty tips, missing days left, and low confidence
• Impact numbers based on a published, citable source instead of made-up figures
• An app that admits when it isn't sure instead of guessing
• A fast pivot from mobile to web that still delivered a working product
• Four people building in parallel and bringing the pieces together on time

What we learned

• Agreeing on the data format first lets a team build in parallel.
• When a plan stops working, changing direction early beats forcing it.
• Honest uncertainty makes an AI tool more trustworthy.
• Environmental numbers need real, citable sources.
• Keeping the scope small (one item per photo) helped us finish something that works.
• Good version control habits save hours when several people share one repo.

What's next for Ripe

• Reminders before your food goes bad
• A running "food saved" counter and scan history
• More recipe and storage tips
• Tools for grocery stores like H-E-B, to decide what to mark down first and which near-date food to send to food banks, plus uses for restaurants and cafeterias

Built with

React Native, Expo, FastAPI, Python, Gemini API, Render, Our World in Data

Built With

• api
• expo.io
• fastapi
• gemini
• git
• github
• googleaistudio
• javascript
• kaggle
• keras
• mobilenetv2
• native
• postgresql
• python
• react
• supabase
• tensorflow
• vs