TasteRoute

Inspiration

Every group has that one friend who always has to pick the restaurant — and dreads getting it wrong. Planning a night out means tab-hopping across maps, review sites, and group chats, and the results ignore who you actually are. A jazz lover gets sent to a sports bar because "top rated" lists know nothing about taste. I wanted a planner that starts from what you love, not from what's popular.

What it does

TasteRoute is an agentic outing planner. You describe your evening in chat — occasion, vibe, city, what you love (music, films, food, anything). The agent:

1. Resolves the taste mentions in your brief to Qloo entities (Qloo /search).
2. Uses those entities as cross-domain taste signals (signal.interests.entities) against Qloo's taste-graph insights (/v2/insights) to find real venues that match your taste profile — never a generic top-rated list.
3. Assembles the picks into a sequenced evening (dinner → cocktails → late-night), shown on a map with a shareable plan link.

Every stop explains itself with a visible "Why" rationale and a match score, so the cross-domain connection — your jazz records steering your cocktail bar — is right there on the card, not hidden in a black box. And you can refine the plan in conversation: cheaper, different vibe, add dessert — without starting over. The LLM never invents a venue: Qloo is the only source of places.

How I built it

• Frontend: Next.js 14 + Tailwind CSS on Vercel — a single chat surface with a Leaflet/OpenStreetMap itinerary view and shareable plan pages.
• Agent: an Express + TypeScript API on Render runs the loop: LLM intent extraction → Qloo entity resolution → Qloo taste-graph insights → LLM itinerary assembly. The Qloo API key stays server-side; the browser never sees it.
• Data: PostgreSQL persists plans so every generated evening gets a shareable link.
• Process: built spec-first (SPEC → DESIGN → TASKS), with Vitest unit tests and Playwright end-to-end tests covering the chat → plan → refinement flow. It ran in a clearly-labelled mock mode until my Qloo hackathon API key arrived, then switched to live Qloo data with no code changes.

Challenges I ran into

• Cross-domain plumbing: mapping free-text taste ("we love Wes Anderson films and natural wine") to the right Qloo entities, then expressing them as insight signals with the right place-type and location filters, took several iterations to stop returning generic results.
• Honesty while blocked: the Qloo key is issued manually by email, so for part of the build the app ran on mock data. I made the health endpoint disclose mock vs live openly rather than faking live results.
• Latency: the brief → entities → insights → itinerary chain has to feel like a conversation, so generation is kept to a single agent pass with a visible "Reading your taste…" state.

Accomplishments that I'm proud of

• A complete, live product — not a demo script: chat in, a mapped, explained, shareable evening out, running on real Qloo data.
• The "Why" on every stop. Judges and users don't have to trust the agent; they can see the taste logic.
• Clean mock → live cutover: the same build that was testable without a key now runs the real taste graph in production.

What I learned

Taste really does transfer across domains — the same signals that describe someone's music and film taste produce venue picks that feel personal in a way ratings never do. Making the agent show its reasoning (the Why, the match score) matters as much as the picks themselves: people follow recommendations they can audit.

What's next for TasteRoute

• Group mode: merge several people's taste profiles into one plan everyone can live with.
• More cities and occasion templates (date night, client dinner, family evening with constraints like the hackathon briefs suggest).
• Reservation hand-off: deep links from a chosen stop to booking.

Built With

• express.js
• leaflet.js
• next.js
• openstreetmap
• postgresql
• qloo
• render
• tailwind-css
• typescript
• vercel