Try it in 30 seconds
Open the demo, press the "Kerala -> Toronto" example, confirm the matches (for Drishyam, pick the Malayalam original or the Hindi remake), and build the passport. No login needed.
Inspiration
Moving to a new country strips away the places that feel like yours. Generic advice like "try the Indian restaurants" ignores that someone raised on Malayalam cinema and someone raised on Punjabi pop want very different tables. We wanted to start from taste (films, music, books), not from a cuisine the user has to name. [Optional: add one sentence of your own story, only if true.]
What it does
You enter a destination and 3 to 8 favorites from home (films, artists, shows, authors). You confirm which Qloo entity each favorite means, for example the Malayalam Drishyam versus the Hindi remake. Taste Passport then:
- derives the cuisines your taste points to in that city from Qloo's own results,
- lists matching places with address, rating, phone and website where Qloo has them,
- runs a Signal Check on every favorite, labeling it either consistent or "pulled in a different direction",
- shows how your taste results compare with a generic baseline for the same city,
- and writes a four-week first-month plan built only from the places found.
How we built it (and how Qloo powers it)
/searchresolves each favorite to a Qloo entity, with a confirm step for ambiguous titles./v2/insightsdoes the core work. We query places in the destination city (filter.location.query) using your favorites as signals (signal.interests.entities), taking up to 50 results. We run the same query with no signals as a baseline and compare the cuisine tags on the two result sets. The cuisines come from that difference. No LLM chooses them./v2/tagsprovides tag IDs for category queries.- Signal Check: one single-signal query per favorite shows which cuisines each favorite alone pulls toward. If a favorite pulls in an unrelated direction, the app reruns the search without it and tells you which one it left out.
- Specific before broad: categories claim places in order of specificity, so Kerala comes before South Indian before Indian.
- Gemini writes the descriptions only. A place with no dishes or description from Qloo gets no blurb. Subjective filler words are blocked in code, and every place named in the output is checked against Qloo's results. If Gemini fails or runs slow, the app falls back to template text and still shows every Qloo place. We tested this with an invalid key.
- Stack: Next.js, TypeScript, Vercel, the Qloo API, Gemini. [34] unit tests use synthetic fixtures, and a secrets scan runs on the repository. No Qloo data is stored in the repo.
Challenges we ran into
- Qloo silently ignores unsupported parameters, so we tested every parameter by checking that results actually changed. Location filtering worked for places but did nothing for movies, music, TV or books, so we narrowed the product to places.
- Our own early metrics misled us. A smoothed ratio looked like "17x" when the baseline count was zero, and an early script reported hardcoded output as Qloo results. We replaced the ratio with plain counts, removed the hardcoded output and added checks to prevent a repeat.
- Entity ambiguity changes results. The same favorites produce different counts depending on which entity a title resolves to (the Malayalam or the Hindi Drishyam), so we added the confirm step.
Accomplishments that we're proud of
- Cuisines come from Qloo's data, not from an LLM guess.
- An honest Signal Check that says when a favorite didn't shape the results.
- A measured comparison against Gemini alone. [Verify against
docs/NUMBERS.md:] Across three profiles (n=5 restaurants each), Gemini's top-3 cuisines matched Qloo's on 2 of 3 for both Indian profiles and 0 of 3 for a Western indie control. So an LLM infers obvious cuisines well, while Qloo adds located places with addresses and ratings and surfaces different results for less obvious tastes. We treat the metro-area match counts (11 of 15) as a rough indicator only, not an error rate. - A pipeline that degrades gracefully instead of failing.
What we learned
Differences from a baseline aren't proof of relevance, so a good signal needs a coherence check. Measuring each Qloo parameter before building on it saved us from several wrong assumptions. Reporting plain counts is more convincing than clever ratios.
Limitations
Results cover the metro area around a city. Qloo exposes no scores, so we rely on its ranking. Weak signals can fail to move results. We don't check live opening hours or availability. Grocery stops, when shown, are rule-based and labeled as such.
What's next for Taste Passport
More categories where our tests show real taste effects (cafes, groceries and bookstores were popularity-led in our tests, so they stay out for now), more cities and language coverage, shareable passports, and persistent caching so a high-traffic demo costs nothing.
Built With
- css
- google-gemini-api
- next.js
- node.js
- qloo-api
- react
- typescript
- vercel
- vitest
- zod
Log in or sign up for Devpost to join the conversation.