This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
What I Built
There is one question my friends can never answer quickly:
“Where should we eat?”
It sounds like an easy question. It isn't.
One person wants something spicy. Someone else wants comfort food. Someone has a strict dietary restriction. Someone doesn't want to spend more than ₹500. And then there's always that one person who says “I'm fine with anything” until everyone picks somewhere.
What usually follows is a long WhatsApp conversation, five restaurant links, a couple of polls, and eventually someone says:
“Fine. You guys decide.”
I've been part of enough of these conversations to realize that the problem isn't finding restaurants.
It's finding one that everyone can actually agree on.
So for this challenge, I decided to build something for my friends instead of building another tool just for myself.
I built BiteVote.
BiteVote is a group dining decision engine that turns the usual restaurant argument into a shared experience. Everyone gets to say what they actually want, hard dietary boundaries are protected, and instead of simply picking whoever gets the most votes, BiteVote tries to find the best compromise for the whole group.
You start by creating a room and inviting your friends. Everyone sets their own budget, cuisine preferences, cravings, and dietary boundaries. Then everyone privately votes on restaurants.
If the group is split, BiteVote offers an optional Bite Blitz, a quick food game where everyone can compete in rounds like Guess the Dish, Guess the Price, and Real or Fake. It's not there to replace the actual decision. It's a fun way to break a close call.
Once the votes are in, Gemma becomes the referee.
But I didn't want to give an LLM a list of restaurants and simply ask, “Which one is best?”
Dietary restrictions are handled first in deterministic code. A restaurant that violates someone's hard requirement doesn't make it to the AI's final decision. Gemma only gets to work with the candidates that are already valid, and then weighs the softer things people disagree about, such as budget, cuisine, cravings, votes, and the occasional tie-break.
The result isn't just a restaurant name.
BiteVote explains why the group ended up there, what each person gained and gave up, and how well the final choice matches the group.
And then I realized there was one more problem.
Even after you finally agree on a restaurant, someone still asks:
“Okay, but what should we order?”
So I added BiteGuide.
Once the group has a winner, BiteGuide searches the web and YouTube for that specific restaurant and looks for dishes that food reviewers, restaurant pages, and food videos actually recommend. Gemma then turns those results into a short list of dishes worth trying, including tasting menus or chef/specialty recommendations when they can be found.
So BiteVote takes the group from:
“Where should we eat?”
all the way to:
“We're going here. And these are the things we should order.”
That's the part I wanted to build for my friends, not another restaurant poll, but something that makes the entire argument a little easier, a little fairer, and hopefully a lot more fun.
Demo
Live at Render: https://bitevote.onrender.com/
Code
You can check out the source code for BiteVote on GitHub:
🍽️ BiteVote — Vote. Match. Eat.
The AI-Powered Compromise Engine that ends the 45-minute "Where should we eat?" debate forever.
Built for the Hacktoberfest 2026 Weekend Challenge: Build for a Friend (#devchallenge #weekendchallenge #hf26challenge).
🌐 Live Application: https://bitevote.onrender.com/
💻 GitHub Repository: https://github.com/ishapalkar/BiteVote_hacktoberfest
🏥 API Health Check: https://bitevote.onrender.com/api/health
🎯 The "Build for a Friend" Story (India First)
Every Friday evening across Indian cities, friend groups and families hit the same dining deadlock:
- Sarah is strict Jain (strictly no onion, garlic, potatoes, or root vegetables) with a budget of ₹300–₹500 and a craving for authentic Maharashtrian / Street Food.
- Rahul is Vegetarian with a budget of ₹400–₹700 craving North Indian tandoor.
- Aisha is Vegetarian with a budget of ₹300–₹600 craving fiery Indo-Chinese.
- Others in the group want to stay strictly within a fair ₹ budget without unexpected splurge bills.
Existing dining apps fail because simple majority voting…
How I Built It
The hardest part of BiteVote was not finding restaurants. It was deciding what the AI should be allowed to decide.
I built BiteVote as a guardrailed decision pipeline where deterministic code handles the boundaries and Google Gemma 2 handles the messy part: balancing different people's preferences.
Gemma is the mediator
BiteVote uses Google Gemma 2 (google/gemma-2-27b-it) through OpenRouter.
Instead of asking Gemma to simply pick a restaurant, I give it structured information about the group:
- Each person's dietary boundaries
- Budget range
- Cuisine preferences and cravings
- Restaurant candidates
- Private votes
- Optional Bite Blitz tie-break signals
Gemma then synthesizes all of that into a structured recommendation.
It returns:
- A winner
- A Match Harmony Score
- Why the restaurant works for the group
- What each person gained and compromised on
- Personalized dish suggestions based only on the available menu data
Hard constraints never reach the model's decision layer
Dietary requirements are different from preferences.
A craving can be compromised. A dietary boundary should not be.
So before Gemma is called, Python applies deterministic filtering to remove candidates that do not satisfy the group's explicit requirements, such as Jain, Pure Veg, Vegan, Halal, Gluten-Free, or known allergen constraints.
This means Gemma is never asked to decide whether a hard dietary restriction should be ignored. Its job is to find the best compromise among the candidates that are already valid.
Bite Blitz
When the group is split between close choices, BiteVote can offer an optional Bite Blitz tie-breaker.
It's a 60-second food game with three rounds:
- Guess the Dish
- Guess the Price
- Real or Fake
The game adds only a small, bounded tie-break signal to the previously selected valid choices. It can influence a close decision, but it can never override a dietary boundary.
BiteGuide
After the group finally agrees on a restaurant, I wanted to solve the next problem:
“What should we order?”
BiteGuide uses SerpApi to search Google and YouTube for the exact restaurant and city.
The search layer looks for recurring recommendations, signature dishes, chef specials, tasting menus when available, food reviews, and source-backed prices.
Those results are then given to Gemma to synthesize into a concise list of recommendations.
The model is instructed to stay grounded in the retrieved information, so it doesn't invent dishes, prices, or tasting menus when the sources don't support them.
The rest of the stack
- Frontend: React, Vite, Tailwind CSS, Lucide Icons
- Backend: FastAPI + Python 3.11
- Database: MongoDB Atlas + PyMongo Async
- AI: Google Gemma 2 via OpenRouter
- Web intelligence: SerpApi
- Deployment: Render
The result is a system where code protects the boundaries, scoring handles the measurable parts, and Gemma handles the human part of the decision: finding a compromise everyone can understand.
Why Does Open Innovation Matter?
Open innovation was crucial for BiteVote, since I didn't want the key component of the product to be a black box over which I had no control.
The problem was complex – six people might have entirely different budgets, cuisines, cravings, and diets, and there was no objectively right solution to it. I wanted to be able to incorporate AI into my decision-making pipeline and be in control of its use.
Using Gemma gave me that flexibility.
It allowed me to precisely control what data the model saw, mix that with my deterministic filtering and scoring, code strict dietary constraints, and influence the way the model would come up with its compromise. I wasn't building the whole product based on the assumptions made by a proprietary API.
It also allowed me to plan for the future: freedom to experiment.
Right now BiteVote uses Gemma 2 through OpenRouter, but tomorrow the same AI layer could easily be evaluated through some other provider or even migrated towards self-hosting without having to rewrite the whole decision-making engine from scratch. It's much harder when your application logic is tightly integrated with the model API.
And that is what open innovation made possible for me: not just using an AI model, but actually designing around it, testing it, replacing it, and building my own rules around the parts that matter.
For a project like BiteVote, that control is what turns an AI feature into an actual product.
Prize Categories
Best Use of Gemma
Gemma 2 is at the core of BiteVote's decision engine. It acts as the group's mediator, weighing preferences, votes, budgets, cravings, and trade-offs after deterministic Python checks have filtered out invalid restaurants. Gemma also powers the synthesis layer of BiteGuide.
Best Use of Render
BiteVote is deployed on Render, giving the project a publicly accessible environment for the frontend/backend application.
Best Use of MongoDB Atlas
MongoDB Atlas is BiteVote's data layer, storing rooms, participants, preferences, votes, restaurant candidates, and decision results.
Best Use of SerpApi
SerpApi powers BiteGuide's live web and YouTube search. After the group chooses a restaurant, BiteGuide searches for current reviews, recommended dishes, chef specials, tasting menus, and source-backed information before Gemma synthesizes the recommendations.


Top comments (0)