Inspiration

Every travel list is the same top 10.

But the music you play, the films you rewatch and the brands you wear say a lot about which cafés, galleries and bars you'd actually enjoy.

We wanted a planner that starts from your taste, and that never makes places up.

What it does

Pick any city in the world, 1–30 days, an optional budget and 3–6 things you love (artists, films, TV shows, books, brands) from Qloo autocomplete.

TasteTrip's agent queries Qloo for the places in that city whose fans overlap most with yours, slot by slot (breakfast, morning, lunch, afternoon, dinner, night), and arranges them into walkable days.

Long stays (up to 30 days) rotate a few day shapes, split Qloo's candidates across days so no place repeats, and fill dry slots with other Qloo places of the same kind.

Every stop shows its Qloo match % and a "Why this fits you" panel with bars showing which of your tastes drove the match, from Qloo's explainability scores. You can swap any stop, regenerate a day, and share a public link.

How we built it

  • Next.js 15 on Vercel, Tailwind + shadcn/ui, Leaflet/OpenStreetMap, Upstash Redis, Zod.

  • A travel-native interface: split-flap departures board, animated world-map flight routes, boarding-pass planner and passport-stamp match scores, in a Burgundy & Blush palette with light and dark modes checked for readable contrast.

  • Qloo endpoints: /search (taste autocomplete), /v2/tags (turns slot categories like "jazz club" into place tags), and /v2/insights with filter.type=urn:entity:place, signal.interests.entities, filter.location.query, filter.tags, filter.hours, filter.price_level.max, filter.exclude.entities (swap/regenerate), bias.quality, filter.popularity.min and feature.explainability=true.

  • An LLM (NVIDIA Nemotron on Nebius Token Factory) does three narrow jobs: choose slot categories per day, group Qloo's candidates by proximity, and write one-line explanations using only Qloo's fields. Tool calls are orchestrated in code and streamed to the UI as a live agent log.

  • A validator rejects any LLM-chosen stop that isn't in that slot's Qloo candidate set, and drops explanations that credit a taste Qloo didn't. If Qloo fails, the app shows an error; there is no LLM-only fallback.

Challenges we ran into

  • Qloo silently ignores invalid parameters, so every filter was checked against the Entity Type Parameter Guide.

  • Keeping the LLM honest: strict JSON + Zod validation + one retry, then a deterministic affinity-and-distance fallback.

  • Building before our API key arrived: a clearly labelled local-only mock let us finish the UI, and it's refused in production.

  • Long trips: a 30-day plan needed paged Qloo results, cross-pool de-duplication and parallel planning to stay around a minute and ~40 Qloo calls.

Accomplishments we're proud of

Cross-domain taste (music and film → food and places) with transparent, per-taste explanations, and zero invented venues.

A typical 2-day plan takes about 10 seconds; six one-tap sample trips span Tokyo, Paris, New York, Mexico City, Cape Town and Sydney.

What we learned

Qloo affinity is aggregate: "fans of X over-index on Y" is not a fact about one person, so the copy is written that way.

What's next

Destination/day-trip suggestions with filter.type=urn:entity:destination, transit-time grouping, and a B2B version for tourism boards and hotels.

Built With

Share this project:

Updates

Submission history