TasteCrew

A group-night planner (a fixed, transparent pipeline) that uses Qloo's Taste AI to find a restaurant and a movie that fit the whole group's shared taste, then splits the planned budget evenly.

Comment

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for TasteCrew

Inspiration

Every group chat has the same argument: where do we eat, and what do we watch afterwards? Everyone has different tastes, and the usual answer is a generic "top 10" list or whatever one person suggests. We asked whether a tool could plan a group night by looking at the real cultural overlap between people's tastes, instead of guessing. Qloo's taste graph turned out to be the missing piece.

What it does

  • Each group member enters a name and a few things they like (artists, movies, TV shows, brands, books, and so on). The group also sets a city, a mood (e.g. "casual dinner"), and a budget per person.
  • TasteCrew runs a fixed, transparent pipeline of Qloo calls. It is a deterministic sequence of steps, not autonomous AI planning:
    1. Resolve taste seeds: each like is mapped to a Qloo entity through Search, limited to taste-signal types.
    2. Mood → tags: the mood text is mapped to Qloo place tags.
    3. Group affinity: all resolved entities, plus the mood tags, go to Qloo Insights together. One call asks for restaurants in the chosen city and another asks for movies.
    4. Pick + split: the top restaurant becomes the dinner pick, with up to three alternatives, and the top movie becomes the entertainment pick. The per-person budget is split evenly across the group, exact to the cent.
  • In one live run on the deployed app (Oct 23) (city set to New York, mood "casual dinner + a film"): the dinner pick was The Flower Shop, with Lucali among the alternatives. Exact picks can vary between runs as Qloo results change.
  • The results appear as cards showing the name, neighborhood, address, price level, rating, image, website link, and Qloo tags, alongside a step-by-step trace of the pipeline. Any partial Qloo failures are shown as readable error messages.
  • GET /api/health shows whether the service is calling the live Qloo API (qlooMode: live) or using offline demo data.

Current limitations

  • The bill is an even split of the planned per-person budget. It doesn't use real prices.
  • The "why it fits" line for each member is a template that combines their likes with the pick. It isn't a generated explanation.
  • The pipeline is a fixed sequence of steps. It doesn't plan autonomously or choose its own tools.

How we built it

  • Backend: Node.js 20 + Express. Endpoints: GET /api/health, GET /api/search?q=, POST /api/plan.
  • Qloo Taste AI API usage (hackathon endpoint https://hackathon.api.qloo.com, X-Api-Key header):
    • GET /search with types limited to artist, movie, TV show, brand, book, place, podcast, and video game, so each like resolves to a usable taste-signal entity.
    • GET /v2/tags with filter.query set to each part of the mood text (e.g. "casual dinner" → urn:tag:good_for:qloo:casual_dinner), keeping only tags that apply to places.
    • GET /v2/insights with filter.type=urn:entity:place, filter.tags=urn:tag:category:place:restaurant, filter.location.query=<city>, signal.interests.entities=<all group seeds>, and signal.interests.tags=<mood tags>, so a single query reflects the whole group's combined taste.
    • GET /v2/insights with filter.type=urn:entity:movie and the same group seeds, for the entertainment pick.
    • Because the tag and location filters don't always exclude everything, the server also checks each result and keeps only restaurants that are actually located in the requested city.
  • Pipeline (server/agent.mjs): a fixed, transparent resolve → mood tags → insights → pick → split sequence that records each step and collects any errors. The split uses integer cents and spreads any remainder so the shares always add up to the total.
  • Mock mode: with no API key, the Qloo client returns local sample entities so the project runs for anyone who clones it. The deployed demo runs in live mode.
  • Frontend: plain HTML, CSS, and JavaScript with no build step. All text from Qloo is HTML-escaped, and only https image and website URLs are rendered.
  • Hosting: Render.

Challenges we ran into

  • Hackathon keys work only against the dedicated hackathon base URL and need the X-Api-Key header, not a Bearer token.
  • In an early version, the place query wasn't limited to dining, and one live run picked a museum (the Guggenheim) as "dinner". We fixed this by adding the restaurant category tag and a city location filter, and by having the server drop any result that isn't a restaurant in the chosen city.
  • Free-text likes sometimes matched the wrong kind of entity. Limiting Search to taste-signal types fixed this.
  • Partial API failures used to be silently ignored. Now they are collected and shown in the UI.
  • Waiting for the API key: we built mock mode first so development wasn't blocked, then switched to live data once the key arrived.

Accomplishments that we're proud of

  • A working live deployment that combines several people's tastes, plus the group's mood, in one Qloo Insights query and returns real restaurants in the chosen city.
  • Transparency: every plan shows which likes were resolved, which Qloo filters and mood tags were used, how many candidates came back, and any errors.
  • Safe, readable result cards, with escaped output and no raw HTML from external data.
  • Small, readable codebase with only two runtime dependencies (Express and dotenv), released under the MIT license.

What we learned

  • Taste data changes what a recommender can do. Without Qloo, a tool can only invent "nice restaurants". With it, the picks come from real cultural affinity.
  • Passing multiple signal.interests.entities into one Insights call is an easy and effective way to model a group.
  • API filters help, but checking the results on the server (category and city) is what makes the output reliable.

What's next for TasteCrew

  • Replace the templated "why it fits" text with explanations built from the actual Qloo tag and affinity overlap for each member.
  • Split the bill by actual menu prices or individual orders, instead of evenly splitting the budget.
  • Weight members' signals so quieter members still influence the result.
  • Let the group vote on the alternatives and re-run the pipeline based on the result.
  • Optional settlement: connect the split to a payment flow so each member can pay their share directly.

Built with

  • Qloo Taste AI API (Search, Tags v2, Insights v2)
  • Node.js
  • Express
  • dotenv
  • JavaScript
  • HTML / CSS
  • Render

Links

Built With

Share this project:

Updates

Submission history