FridgeTinder

Inspiration

The average Aussie household bins over $2,500 of food a year, and the #1 reason is painfully small: you have eggs but no tomatoes, your neighbour has tomatoes but no eggs, and neither of you knows the other exists. Meanwhile every dating app has solved exactly this problem - matching strangers by compatibility. So we asked the dumbest question of the weekend: what if fridges could swipe right on each other?

Built for SYNCS HACK 2026 - theme: Blocks that make up the world. Ingredients are blocks: alone they sit and expire, combined across two fridges they become a meal and a new connection between neighbours.

What it does

It's a match! Your fridge and a neighbour's fridge just swiped right on each other.

FridgeTinder is Tinder for fridges: scan your fridge with your camera, AI reads the ingredients, finds nearby fridges whose contents combine with yours into real dishes, and sends an anonymous AI-written invite to cook together - before the food goes to waste.

Everything in the app is real and running - the camera gate, the ingredient extraction, the matching, the invites. Nothing is staged. And if you have no one to test with, the app ships with 11 seed neighbours in Camperdown (their fridge contents come from running the actual vision model on actual fridge photos) - they'll show up in your swipe deck, receive your invites, and accept after ~25 seconds so you can watch the full loop solo.

How we built it

The team:

Yang Chong - Designer, programmer
Ruihan Zhao - Designer, UI programmer
Cursor Agent - The Workhorse

JS frontend - login page, swipe deck with pointer gestures, Leaflet map. Express backend with JSON files as the "database". Gemini does everything AI: the camera gate runs on a small fast model polled every 3 seconds, extraction and matching and email-writing run on a bigger one. We spent a lot of time editing prompts for both Cursor and Gemini LOL.

Challenges we ran into

Google deprecated our model during the hackathon. New API keys started returning 404 on gemini-2.5-flash, and the keys themselves come in a new format now, so for a while we were convinced the key was broken. It wasn't. We read the raw error, found the migration notice, switched to 3.6-flash.

Then 3.6-flash turned out to "think" by default - our matching call took 33 seconds, which kills a live demo. thinkingLevel: low got it to 13s and we couldn't tell the difference in output quality.

Also we blew through the free tier in literally one test run, because polling a vision model every 3 seconds adds up fast. Split the models, tuned the interval, paid up (a whole user journey costs about 3 cents, we'll survive).

The hardest prompt problem: making the model admit it can't see something. Early versions confidently listed food inside closed containers. Now uncertain items go in their own list with a reason, and the user chooses.

Accomplishments that we're proud of

Everything you see in the design is actually built and actually runs. Login, camera gate, ingredient extraction, matching, swipe deck, map, invites, acceptance, contact exchange - the whole loop works end to end on a real phone, live, in about a minute. No mockups, no hardcoded responses, no "imagine this part works" slide.

What we learned

Prompts need version control like code does. The API you build on can stop existing for new users halfway through a weekend, so mock mode isn't optional.