Inspiration

Tampa Taste Trail was inspired by the gap between finding nearby places and finding places that connect with someone’s interests.

Music, movies, and food can express different parts of a person’s taste. The project brings those interests into one outing-planning workflow, using cultural intelligence to discover candidates and clear source labels to help users review them.

The goal is a more personal starting point for exploring Tampa, with the user making the final decisions.

What it does

Tampa Taste Trail turns a plain-language request into an editable taste profile, then uses Qloo to discover nearby places.

For example:

“I like Burna Boy, the movie Interstellar, and spicy food. Plan a relaxed evening in Tampa for two people with a total budget of $100.”

Users can:

Review and edit extracted interests and outing preferences.
Confirm artist, movie, and food matches returned by Qloo.
Build a small itinerary from geographically validated places.
Replace individual stops with alternatives from the same discovery results.
Change the area, budget, or pace and rebuild.
Copy the itinerary with its sources and limitations.

The public application works in a browser without an account.

How it was built

The application uses Next.js, React, TypeScript, and server-side API routes. Zod validates incoming preferences and external response data.

Gemini extracts a structured taste profile from the user’s request. The user reviews that interpretation before discovery begins.

Qloo Search and Tags resolve the interests into candidate IDs. After the user confirms matches, the server revalidates those IDs and sends them to Qloo Insights with geographic constraints.

The application validates returned coordinates, removes unsuitable records, and uses category tags and straight-line proximity to suggest an order.

An expandable workflow trace shows the resolution, validation, discovery, and assembly stages. Each stop identifies the confirmed signals used in its discovery query.

Provider credentials stay on the server. The application is hosted on Render, and its source code is publicly available under the MIT license.

Why Qloo is essential

Qloo supplies the live cultural-discovery candidates. Confirmed artist and movie IDs, together with taste tags, directly enter the recommendation request.

This makes Qloo part of the application’s core decision process. Gemini interprets the brief; Qloo provides the cultural discovery; the application validates and organizes the returned places.

A separate fictional preview supports interface exploration. It is clearly labeled and never silently replaces a failed live request.

Challenges

One challenge was handling API response formats while maintaining strict validation. The integration needed to accept compatible category representations while continuing to reject malformed IDs and incompatible entities.

Another challenge was separating cultural relevance from practical certainty. A taste-based result does not establish current opening hours, prices, availability, accessibility, or group capacity.

Those details remain visibly unverified. The budget is presented as the user’s target, and the map is labeled as a schematic rather than navigation.

Keeping the interface consistent after edits was also important. Changing preferences clears stale itinerary results, while stop replacements preserve the validated discovery pool and source information.

Verification

The project passed 48 automated tests, formatting, lint, TypeScript checks, a production build, and GitHub CI.

A public Chrome audit exercised real Gemini extraction and Qloo discovery across music, film, and food. It verified a two-stop Tampa plan and a revised three-stop Ybor City plan.

The audit also checked:

Stop replacement and clipboard export.
Geographic validation and unique stop IDs.
Revised budget, area, and pace preferences.
Keyboard navigation and desktop/mobile layouts.
Rejection of invalid inputs and forged signal IDs.

Empty and outage presentation were tested separately with explicit browser mocks. One Gemini request failed transiently; retry succeeded, and explicit rule-based recovery was verified.

These checks demonstrate functionality. Recommendation quality and user impact have not been measured through a user study.

What I learned

A key technical lesson from the implementation is that grounding requires validation throughout the workflow. A successful API response still needs checks for identifiers, categories, coordinates, and compatibility with the user’s request.

The project also highlights the value of separating responsibilities. Structured AI extraction, cultural discovery, geographic validation, and itinerary presentation each have a clear role.

Communicating uncertainty is part of the product itself. Source labels, editable preferences, visible unknowns, and recovery controls help users understand what the application has established and what still needs checking.

What’s next

Future work would evaluate recommendation quality with users, improve the variety of stops, and incorporate reliable sources for opening hours and practical costs.

Further development could explore more cities and better ways to explain how different cultural signals influence discovery.

The priority is to make the recommendations more useful while preserving clear provenance and user control.