Taste Buds

Discover restaurants with friends. Eat better together.

Comment

Inspiration

We wanted to solve the “where should we eat?” problem in a way that felt social and personal. Too many apps show generic lists; we wanted recommendations that understood who you’re with and what you all like. That led to two core ideas: an AI chat that suggests places using your location and preferences, and a social taste graph that visualizes how you and your friends overlap in food preferences—so picking a spot for the group actually feels informed.

What it does

  • AI restaurant chat: Users ask in natural language (e.g. “Good sushi near me” or “Date night for two”) and get conversational recommendations powered by Gemini, with optional location and friend context.
  • Restaurant search: Search is backed by Google Places (text search, photos, ratings) and results are stored in Supabase for the app and social features.
  • Social taste graph: A dedicated Network tab shows an interactive graph of you and your friends. Edges show similarity scores and reasons (e.g. shared cuisines, shared restaurants), so you can see why you’re taste-aligned.
  • Friends & profiles: Add friends, view their profiles, and manage your own—including profile photo uploads to Supabase Storage and a bio.
  • Reviews: Users can leave reviews on restaurants; the backend and Supabase store and serve them.
  • Maps: Restaurant results can be viewed on a map for quick discovery.

How we built it

  • Mobile (Expo + React Native + TypeScript): Cross-platform app with tabs: Home (AI chat), Search, Network (social graph), Map, Friends, and Profile. Auth via Supabase (Google sign-in). The app calls our FastAPI backend for all protected or API-key-dependent features.
  • Backend (FastAPI + Python): Handles JWT verification, serves the social graph (/api/network/graph), runs the Gemini recommendation chat with optional @mentions for group preferences, and proxies Google Places for search and photos. Uses Supabase for profiles, friends, restaurants, reviews, and profile image storage.
  • Social graph: Similarity is computed from stored preferences (cuisine weights, taste profile) and restaurant visit data, then exposed via API; the frontend renders an interactive graph with edge tooltips (score + reason).
  • Deployment: Backend on Render; mobile runs in Expo Go or simulators, pointing at the deployed API. Supabase is the single source of truth for auth and data.

Challenges we ran into

  • Security: Keeping API keys and tokens server-side only. The mobile app only gets the Supabase anon key and backend URL; every protected route verifies JWTs. Getting this right took careful wiring between Supabase auth and our FastAPI middleware.
  • Social graph design: Deciding what to store (preferences, friends, visits) and how to compute similarity so the graph felt meaningful without over-engineering in a short timeline.
  • Group-aware AI: Supporting @mentions in the chat so Gemini could reason about “me + my friends” meant resolving display names to profile data and injecting that context into the prompt in a clear, reliable way.
  • Judge-friendly setup: Enabling others to run or review the app without committing secrets. We documented only the public env vars and kept backend secrets in Render; judges can review code and, with the shared frontend config, run the app locally.

Accomplishments that we're proud of

  • Shipping a full-stack app in a hackathon: mobile UI, backend API, social graph, AI chat, search, reviews, and maps.
  • Building the social taste graph as a first-class feature—both the data model and the interactive visualization—so “who do I eat like?” is visible at a glance.
  • Making recommendations group-aware with @mentions so the AI can suggest places that work for everyone in the conversation.
  • Deploying the backend to Render and documenting the repo so judges can understand and (with env config) run the project without ever touching our secrets.

What we learned

  • How to tie together multiple APIs (Supabase, Google Places, Gemini) behind one backend so the client stays simple and keys stay server-side.
  • How to design and expose a “social graph” feature—from profiles and preferences to similarity scoring and an API that the frontend can render clearly.
  • Practical auth and deployment: JWT verification on FastAPI, env handling for Expo, and keeping the repo safe for public submission while still runnable by judges.

What's next for Taste Buds

  • Richer graph: Use more signals (reviews, ratings, check-ins) to improve similarity and add filters (e.g. “friends who love brunch”).
  • Push & notifications: Remind users when friends add reviews or when a highly matched friend tries a new place.
  • Discovery feed: A feed of “friends’ recent finds” and “trending near you” to reduce decision fatigue.
  • Native builds: EAS Build for TestFlight/Play Store so users don’t need Expo Go, plus deeper integration (e.g. share sheets, widgets).
  • Offline & performance: Cache graph and recent recommendations, and optimize cold starts on the free tier.

Built With

Share this project:

Updates