MeetEat — Group Dining Recommender

One fair restaurant pick for the whole group — and a plain-language reason everyone trusts.

🌟 Inspiration

Every group chat has the same conversation.

"Where should we eat?" "I don't mind, you decide." "Anywhere is fine with me."

Twenty minutes later, nobody has decided anything — and someone quietly ends up somewhere they can't eat, can't afford, or can't get to in time.

We built MeetEat because the real problem isn't finding a good restaurant. It's making a fair group decision when everyone has different locations, dietary needs, budgets, and tastes — and nobody wants to be the one who makes the wrong call. We wanted to give every group a neutral, trustworthy AI that takes the social pressure out of the decision entirely.

🍽️ What It Does

MeetEat is an AI-powered group dining coordinator built for the UK market. Here's the flow:

One person creates a session and shares a link with the group
Each participant fills in their own preferences — location (via postcode or GPS), cuisine likes and dislikes, dietary requirements, max budget, and how they're travelling and how long they're willing to travel
MeetEat's algorithm runs in the background, first eliminating restaurants that fail anyone's hard requirements (halal, allergies, budget ceiling, travel time, opening hours), then scoring the remaining candidates across four dimensions: geographic fairness, cuisine match, venue quality, and occasion fit
Three restaurants are returned — each labelled with its archetype (Best Overall, Closest to All, Best Taste Match), a per-person travel time breakdown, a score bar chart, and a one-sentence AI-generated reason in plain language
The group votes in a 60-second countdown, and the winner is confirmed with a direct Google Maps navigation link and booking link

Key design decisions:

Vegetarian and vegan are soft preferences, not hard blockers — one person's dietary preference shouldn't exclude the whole group from a restaurant where they'd have plenty of options
Price is a hard filter, not a scoring dimension — a restaurant outside anyone's budget simply doesn't appear
Geographic fairness is the highest-weighted dimension (30 pts), calculated not just on average travel time but on variance — no one participant should be disproportionately sacrificed for the group

🛠️ How We Built It — Team Breakdown

Area	Owner
Theme definition, requirements analysis, system design	Yixuan Cao
Requirements analysis & system design	Lejing Wu
Frontend development	Fengzhe Li
Backend development	Yixuan Cao

🚧 Challenges We Ran Into

The biggest challenge was Google Places API quota.

Our original architecture called Google Places Nearby Search and Distance Matrix API live for every search — the right approach for production. During the hackathon, we hit quota limits that made live API calls unreliable for demo conditions.

Our solution: we built a static restaurant dataset by pre-scraping a curated set of London restaurants across key areas (Shoreditch, Spitalfields, Borough, Covent Garden, Canary Wharf), storing their cuisine types, price levels, ratings, coordinates, opening hours, and halal/vegetarian metadata. The scoring algorithm runs identically against this static data — geographic fairness, cuisine matching, and all filtering logic works exactly as designed. For the demo, this actually made the experience more reliable and faster than live API calls would have been.

The trade-off is obvious — real-world coverage requires the live APIs. But the core product logic, the UX, and the AI layer are all fully functional.

Other challenges:

Designing the soft vs. hard dietary distinction required careful UX copywriting — users needed to immediately understand that selecting "vegetarian" wouldn't veto restaurants for the whole group
Balancing the five scoring dimensions and dynamic weight adjustments (e.g. when only 2 participants join, or when budgets don't overlap) took several iterations to feel intuitively fair

🏆 Accomplishments That We're Proud Of

We built something that fits perfectly inside the ZYMIX ecosystem — and genuinely leverages GLM's strengths.

GLM isn't just decorative in MeetEat. It does three things that matter:

Cuisine inference — Given a restaurant name and its Google Places types array, GLM infers the most accurate human-readable cuisine label (e.g. distinguishing "Modern British" from "Pub food" from "Fish & chips")
Occasion fit scoring — GLM evaluates whether a restaurant's ambience, noise level, and service style matches the group's occasion (birthday, business dinner, casual, date night, celebration) in a way that simple keyword matching can't
Bilingual reason generation — GLM generates a concise, natural-sounding recommendation sentence in both English and Chinese, calibrated to the specific group's constraints. "Everyone within their travel limit, halal certified, rich vegetarian menu — zero cuisine conflicts" is a genuinely useful output, not a template fill-in

The result is an app that uses AI where AI actually adds value — and falls back to deterministic logic everywhere else.

📚 What We Learned

How to use the tools we were given — and when not to.

The hackathon forced us to think carefully about where GLM belongs in the product versus where a well-designed algorithm does a better job. Early prototypes tried to use GLM for the scoring itself — it was slower, less predictable, and harder to explain to users. The final version uses GLM only for the three tasks above, and the scoring is pure deterministic logic. That boundary made both parts better.

We also learned:

Demo-ability is a product requirement, not an afterthought. Every feature decision was filtered through: "can we show this clearly in 3 minutes on stage?" That discipline cut scope significantly and made the final product much tighter
Soft vs. hard filtering is a UX problem, not just a logic problem. The algorithm distinction is simple. Communicating it to users — so they don't assume vegetarian means the whole group goes vegan — required multiple rounds of copy iteration
Scoring transparency builds trust. Showing users a bar chart breakdown of why each restaurant scored the way it did turned out to be one of the strongest demo moments. People immediately understood and trusted the recommendation in a way they wouldn't have from a ranked list alone

🚀 What's Next for MeetEat

The static dataset and demo scope were always a starting point. The roadmap:

Short term (next 2 weeks)

Integrate live Google Places API with proper quota management and caching
Deploy with Supabase Realtime so multiple devices can join the same session simultaneously via the shared link
Expand restaurant coverage beyond the demo dataset to full London

Medium term

OpenTable / Resy live availability API so users can book directly from the results page
Wait time data integration
Actual price estimates including the 12.5% UK service charge
Weather-aware travel mode suggestions (rainy day mode)

Longer term

Expand beyond London to all major UK cities
Session history and group favourites
A "regular group" feature — save your group's preferences so you don't re-enter them every time
Integration with calendar tools to align everyone's availability, not just their travel preferences

MeetEat solves a real coordination problem that happens millions of times a week in every city. The hackathon version proves the core concept works. The production version just needs the APIs, the scale, and the time.

Built at the HackLondon 2026 Hackathon · London · June 2026