Group Taste Match

A new Beli feature that decides the perfect restaurant for a group of hungry friends.

Comment

Inspiration

We've all been in that group chat where deciding where to eat takes longer than actually getting to the restaurant. One person wants sushi, another is on a budget, someone has dietary restrictions, and nobody wants to make the final call.

Beli has made discovering, ranking, and sharing restaurants a social experience. But what if it could also help friends decide where to eat together?

That inspired Group Taste Match: an independent concept feature for Beli that turns individual tastes into one group decision. Instead of giving everyone another list of restaurants to debate, we wanted AI to handle the compromises and help the group actually make plans.

What it does

Group Taste Match helps 2–6 friends agree on one restaurant without the endless back-and-forth.

Here's how it works:

  1. Create a room: A host chooses a meeting area and time, then shares an invite link with friends.
  2. Share your cravings: Everyone describes what they're in the mood for using voice or text. The app considers their requests alongside their restaurant taste history.
  3. Clarify when needed: If an ambiguity could change the recommendation, the app privately asks the affected person one follow-up question.
  4. Find the best match: AI evaluates restaurants against the group's tastes, budgets, dietary requirements, travel preferences, and simulated availability.
  5. Make the call: If a meaningful tradeoff remains, the host can answer one final question. Otherwise, the app makes the decision automatically.
  6. Go eat: Everyone receives the same restaurant recommendation, with an explanation of why it fits the group.

If no restaurant satisfies the group's hard requirements, the app says so rather than inventing a match.

Try the live prototype

How we built it

We built Group Taste Match as a mobile-first, full-stack TypeScript application using React, Vite, and Cloudflare's developer platform.

The architecture combines several technologies:

  • Cloudflare Workers + Durable Objects: Power multiplayer rooms with SQLite-backed state, real-time WebSocket updates, and server-controlled deadlines.
  • Deepgram Nova-3: Transcribes voice recordings into editable text.
  • GPT-OSS 120B: Interprets natural-language preferences, identifies constraints, and generates human-readable explanations.
  • Cloudflare Clef: Scores how well each restaurant fits each diner's preferences, allowing application code to make the final group decision.
  • Deterministic safeguards: Independently enforce hard requirements such as budgets, dietary restrictions, opening hours, and availability before a recommendation is shown.

We curated a dataset of 30 real NYC restaurants using sourced restaurant information, alongside eight synthetic taste profiles and simulated reservation availability. No proprietary Beli data is used.

We also implemented two interchangeable recommendation pipelines: one powered by Clef and another using a general-purpose LLM directly. To compare them, we built a reproducible experiment harness measuring recommendation quality, latency, cost, and constraint adherence.

Challenges we ran into

The hardest problem wasn't recommending a good restaurant. It was recommending one that worked for everyone.

A restaurant might perfectly match four people's tastes while completely ignoring the fifth person's dietary restrictions. We had to distinguish non-negotiable requirements from preferences that could reasonably be compromised.

Another challenge was deciding when AI should ask questions instead of making assumptions. Too many clarification questions defeat the purpose of making restaurant planning effortless, but too few can produce poor recommendations.

We also discovered that a specialized scoring model doesn't automatically make better decisions. In our initial experiments, Clef was significantly faster than the LLM baseline, but its fit scores sometimes prioritized general atmosphere over explicitly requested cuisines. This pushed us to revisit how individual scores should translate into a group recommendation.

Finally, coordinating multiple participants, voice transcription, deadlines, reconnections, and private inputs required careful state management to keep the experience seamless.

Accomplishments that we're proud of

We're especially proud of turning a product idea into a fully deployed, real-time multiplayer prototype, rather than stopping at a mockup.

We built an end-to-end experience spanning room creation, voice input, AI interpretation, private clarification, restaurant evaluation, and a shared final recommendation.

But our biggest accomplishment was treating the AI architecture as a question to investigate, not an assumption.

We designed and ran an experiment using 60 synthetic group scenarios, including 40 held-out cases, with 240 fixed-state decision runs and 80 complete-flow sessions.

The experiment produced measurable findings:

  • Zero delivered hard-constraint violations across both evaluated pipelines.
  • Clef was roughly 4× faster in median fixed-state decision latency (5.2 seconds versus 23 seconds).
  • Automated recommendation-quality results showed no conclusive winner, while a blinded review conducted by the developer favored the LLM baseline on differing restaurant choices.

We documented the methodology, results, limitations, and tradeoffs in a reproducible experiment report.

What we learned

The best AI model isn't necessarily the best AI product.

Our experiments reinforced that model selection is only one piece of the puzzle. How preferences are interpreted, how constraints are enforced, and how individual satisfaction is aggregated can matter just as much.

We learned that specialized models like Clef can offer meaningful speed advantages, but faster decisions aren't valuable if they overlook what users actually want. We also learned that deterministic code should enforce critical constraints rather than relying on an LLM to follow instructions perfectly.

Most importantly, we saw the value of testing our assumptions. The original Clef selection policy didn't perform as well as we'd hoped, so we revised the deployed prototype to optimize average diner fit after enforcing hard requirements. That revised policy still needs its own held-out validation.

Building Group Taste Match helped us think beyond whether an AI system can make a recommendation and focus on whether that recommendation is useful, fair, and trustworthy.

What's next for Group Taste Match

The next step is to move beyond synthetic scenarios and validate the experience with real groups of friends.

We want to test whether Group Taste Match actually reduces the time and effort required to plan a meal, whether everyone feels represented in the final decision, and whether groups would use it again.

On the technical side, we'd like to rerun our evaluation with the revised Clef selection policy, improve recommendation quality and latency, and expand beyond our initial 30-restaurant dataset.

Longer term, the vision is to bring group decision-making into Beli itself, using friends' real restaurant histories and preferences to make discovering your next favorite restaurant something you can do together.

Less debating. More dining.

Built With

Share this project:

Updates

Submission history