Inspiration

Big chains pay agencies to understand their customers. The owner of a darshini in Bengaluru or a trattoria in the West Village has nobody. They market alone, with no time and no data, and the advice they get ("play soft music", "run a weekend special") is the same for every restaurant on earth.

The numbers say this is a big, real problem:

  • 56% of India's food-service market is still unorganised, mostly small independents (NRAI India Food Services Report 2024).
  • The US had 412,498 independent restaurants at the end of 2025, down 2.3% in a year while the top chains grew (Technomic via Nation's Restaurant News).
  • Marketing is a top-three pain point for restaurant operators (Toast, 2025 Voice of the Restaurant Industry), and four in five small business owners say their marketing is at best "somewhat" effective, mostly done alone without a plan (State of Small Business survey, October 2025).

What these owners lack is not ideas. It is knowing who their diners are as people: what they watch, listen to and buy. That is exactly what Qloo knows.

What it does

The owner taps a sample restaurant or types three things: the kind of place, the area, and who comes in. In under a minute (the first plan arrived in 15–42 seconds in our 10-city test) TasteMenu builds:

  1. Your crowd. The restaurants most like yours in your city, and the films, shows, music artists and brands their diners over-index on, with Qloo affinity scores and an age/gender lean.
  2. This week's plan. Four actions: a menu idea, the music to play, an event, and a partner cross-promotion. Each shows why it will work, the Qloo results behind it, and a "watch out" note when a signal does not fit (for example an EDM-loving crowd at a calm family restaurant).
  3. Timed to what is coming up. Real occasions for that city in the next weeks (Dussehra on 20 Oct and Diwali on 8 Nov in Bengaluru; Halloween and Thanksgiving in New York), with verified dates. The plan picks the one that suits the restaurant and the crowd.
  4. Ready to send. For every action: a WhatsApp message in English and the city's language in its own script (Kannada in Bengaluru, Tamil in Chennai, Spanish in New York), an Instagram caption, specials-board text, a staff briefing, a partner message and a checklist. Every action except music gets a poster (1080 × 1350) with the headline in both languages; the music action gets a crowd playlist that opens in YouTube Music or Spotify.
  5. Your menu vs your crowd. Upload last month's item-wise sales (Petpooja or any POS CSV) or try the sample month. Every dish is matched to a Qloo dish tag and scored for crowd fit, then sorted into Push, Fix (the crowd loves it but it does not sell: fix the name, price or menu spot) and Drop?, plus dishes your crowd's favourite places are known for that you do not serve.
  6. Test an idea before spending on it. "Weekend biryani counter or breakfast menu?" Each idea is scored for this crowd against the same Qloo signals, so the scores can be compared directly. "How am I different from Vidyarthi Bhavan?" compares taste traits only your kind of place has, only the competitor has, and both share.
  7. Without Qloo vs with Qloo. The same model answers the same question with no Qloo data, shown side by side, with a count of the verified taste signals the plan rests on (between 7 and 13 per plan in our test; the plain chatbot has none).
  8. A taste report to keep. "Save PDF" builds a full A4 report: the week at a glance, the crowd, every action with its messages and poster, menu vs crowd, the ideas tested, the chatbot comparison, and every Qloo call made.

How we built it

  • Agent loop (src/agent.mjs): a Gemini model plans and calls tools. Our own tools (gather_taste_evidence, analyze_sales, rank_ideas, compare_competitor) sit on top of Qloo, the raw Qloo tools are exposed with their live MCP schemas, and two publishing tools stream the plan and the message kit to the phone.
  • Qloo through MCP (src/qloo.mjs): we run Qloo's official qloo mcp server and call it over stdio, with a queue, backoff on 429s and a 24-hour cache. Tools used by our code: find_tags, recommend, entity_tags, audience_demographics, describe, compare_audiences; the agent can also call rank, recommend, describe and find_tags directly.
  • Evidence engine (src/evidence.mjs): cuisine → Qloo tag → peer restaurants in the city → the peers' audience used as signals for films, shows, artists, brands and partner places → what peers are known for → demographics. Every call goes into a trace the owner can open.
  • Sales × Taste (src/sales.mjs): parses most POS exports, matches each dish to a Qloo dish tag with fallbacks ("Biryani" → "Biryani restaurant"), and scores crowd fit with the restaurant's peers as taste signals.
  • Front end: a single HTML file, mobile-first, with bottom tabs, bottom sheets and the poster drawn on a canvas in the browser (Noto Sans for Indian scripts).
  • Hosting: Google Cloud Run, secrets in Secret Manager.

Trust rules in code

  • Every number on the board comes from Qloo. When the plan is published, each evidence item is matched against that session's Qloo responses; Qloo's own value replaces the model's, unknown numbers are removed and unknown names are hidden (verifyPlan).
  • No gap-filling. When Qloo has no signal, the agent says so instead of answering from general knowledge.
  • No invented facts in messages. Prices, discounts, hours and dates are placeholders unless the owner gave them; occasion dates come only from the verified calendar.
  • Privacy. Only the type of restaurant and the area go to Qloo. Uploaded sales stay in session memory and are never saved.

Challenges we ran into

  • Neighbourhoods return nothing. Qloo resolves "Bengaluru" but not "Jayanagar, Bengaluru", so the agent searches at city level and keeps the neighbourhood for the owner-facing text.
  • Affinities bunch together. For one crowd, most scores sit between 0.95 and 0.99, so crowd-fit tiers and bars are relative within a menu or a list of ideas, and we say so on screen.
  • Thin dish tags. Specific dish tags often have no places in a city; trying the next-best tag fixed most "no signal" results.
  • We dropped a feature to stay honest. We built "trending with your crowd" on Qloo's trends endpoint, but on the hackathon dataset the series were flat for 20 weeks, so every "rising" number would have been noise. We replaced it with occasion timing on verified dates.
  • The model invented numbers once (an "affinity 1.0" for Burrata, which Qloo had returned as a tag with no score). That is why verifyPlan exists.
  • Speed. The first version took 77 seconds. A lower reasoning effort, a cache, and pre-warming the sample restaurants brought it down: in the 10-city test on the live app the first plan arrived in 15–42 seconds and the full kit in 29–57 seconds.

Accomplishments that we're proud of

  • It produced a full four-action plan for all 10 restaurants in 10 cities we tested, in India and abroad (see the test table), with every evidence number matched to a Qloo response, and wrote the WhatsApp message in the local script.
  • The owner does not get a report; they get finished work: messages, a poster, a playlist and a checklist.
  • Sales × Taste joins the restaurant's own sales with Qloo's taste graph, which no generic chatbot can do.

What we learned

  • Taste data is thinner where my users are. Qloo returned the full 8 similar places for a London or New York restaurant, but only 1 for an Irani café in Mumbai. The tool has to say "not enough data" instead of guessing.
  • Models copy the nearest example. Twice the AI wrote the WhatsApp message in the wrong language (Spanish for London, Kannada for Chennai) because it copied an example from the instructions. The fix both times was to let code decide the language, not the model.
  • Owners want finished work, not insight. A ready WhatsApp message and poster are worth more to them than a chart.

What's next

  • WhatsApp Business integration so the weekly plan arrives on Monday morning.
  • Direct POS connectors (Petpooja, Toast, Square) instead of CSV upload.
  • Before/after tracking: mark an action done, then compare the next month's sales.

Test run

We ran ten restaurant descriptions through the live app (scripts/eval.mjs, 12 Oct 2026). Every run made 9 Qloo calls, all of which returned data.

Restaurant City Qloo cuisine tag Similar places Verified signals in plan Evidence dropped Occasion picked Message language First plan
Pure-veg Udupi, Jayanagar Bengaluru Udupi 8 9 0 Dussehra / Dasara Kannada 42 s
Biryani cloud kitchen, Koramangala Bengaluru Biryani restaurant 8 8 0 Dussehra / Dasara Kannada 27 s
Irani cafe, Colaba Mumbai Irani Cafe 1 7 0 Dussehra / Dasara Marathi 30 s
North Indian dhaba, Connaught Place New Delhi North Indian 8 12 0 Dussehra / Dasara Hindi 31 s
Chettinad, T. Nagar Chennai Chettinad 8 9 0 Dussehra / Dasara Tamil 30 s
Hyderabadi biryani, Banjara Hills Hyderabad Biryani restaurant 8 9 0 Dussehra / Dasara Telugu 28 s
Bengali home-style, Park Street Kolkata Bengali 8 8 0 Durga Puja Bengali 42 s
Italian trattoria, West Village New York Italian restaurant 8 10 0 World Food Day Spanish 15 s*
Taqueria, Silver Lake Los Angeles Taqueria 8 13 0 World Food Day Spanish 26 s
Modern Indian, Shoreditch London Modern Indian 8 9 0 World Food Day English only† 40 s

All ten plans had four actions, a message kit for each action, posters, and the plain-chatbot comparison. Each crowd profile had 6 films, 6 music artists and 6 brands from Qloo.

* The first New York run lost its connection mid-stream; the rerun is shown.

† The first London run wrote the second-language message in Spanish, a rule meant for US cities. We fixed it (English-speaking cities outside the US now get English only, enforced in code) and reran London; the rerun is shown. On 28 Oct the full 10-city test was re-run on the live app (10/10 pass), and a Chennai message that came out in Kannada was fixed the same way: the language is now chosen in code.

Sources

Built With

Share this project:

Updates

Submission history