Inspiration Independent cooks and small food operators guess their way into expensive mistakes. They pick a dish, then find a venue and an audience by trial and error: wasted ingredients, an empty tasting night, a pitch to the wrong venue owner. We wanted a free tool a chef can open and get an answer from in two minutes: does my concept have an audience in this city, and where could I try it?
We looked at what already exists, tools like Tastewise and Datassential. They're solid, but they're enterprise platforms with quote-based pricing and a sales-demo onboarding flow, built for marketing teams at large food brands. An independent chef can't just open one and get an answer for a single concept. That gap, self-serve, free, scoped to one concrete decision, is what we set out to fill.
What it does You type a dish or menu concept in plain language and one or more cities. Dish-Market Fit Advisor:
Has a Gemini agent map the concept to Qloo taste tags by calling Qloo itself: it searches each part of the concept, then checks which tag actually has venues in the city. For "Korean fried chicken with natural wine pairing" it anchors on Korean Fried Chicken, where a keyword match would settle for the broad Korean. Finds real, named venues in each city, with address, rating, price level, opening hours, dietary tags, and a phone number. Pulls the age/gender audience affinity for each matched venue, plus what reviews of those venues talk about. Projects the taste signal into other domains (brands, TV shows, artists, podcasts) through Qloo's cross-domain graph, seeded with the matched venues themselves, so you see what their actual regulars gravitate toward. Has the agent write a verdict (fit rated strong, moderate or weak), a recommended venue, a 4-week pilot plan scheduled from that venue's real opening hours, menu adjustments and risks, each item citing the numbered Qloo facts it relies on. Drafts a ready-to-send outreach letter to the recommended venue's owner. Compares multiple cities side by side, and exports a print-ready PDF of the findings. An honest "weak fit" is a valid answer: for a Neapolitan concept in a city of Detroit-style pizzerias, the tool says so.
Where the facts come from. Every venue, rating, hour, phone number and demographic number is a live Qloo API result. The language model never states a fact of its own: it chooses what to look up and turns cited facts into a plan. Code, not prompts, enforces this: items with no valid citation are dropped, the recommended venue must be one of the matched venues and must cite facts about that venue, and tag ids must have been returned by Qloo. Tapping a citation shows the fact behind the claim. If the agent picks a tag with too few venues, code overrules it with the better-supported baseline tag and says so. If the LLM is unavailable, the app falls back to the deterministic pipeline and tells the user.
How we built it Next.js 16 (App Router, Route Handlers) with TypeScript and Tailwind CSS, no database. The server pipeline calls GET /v2/tags for semantic tag resolution, GET /v2/insights with filter.type=urn:entity:place for venue discovery, urn:demographics for audience affinity, and urn:entity:brand|tv_show|artist|podcast with signal.interests.entities plus signal.location for cross-domain affinity. The agent runs on Gemini (gemini-3.5-flash-lite) through the Vercel AI SDK: a tool loop with search_tags and find_venues for tag selection, then a structured, citation-bound analysis step. Results are cached for 12 hours and the UI says when a result comes from the cache.
We prototyped the agent loop on three frameworks (Vercel AI SDK, Ax, TS-DSPy) and compared them on the same five concepts, twice each. Only the AI SDK gave identical results across repeated runs without workarounds, so we shipped it.
Challenges we ran into Qloo's rate limit. The hackathon key allows 5 requests/second, shared by every request the server makes. A single lookup fanned out several calls in a burst and city comparisons multiplied that, producing confusing "no venues found" results that were silent 429s. We serialize every outbound Qloo call through one spaced queue with patient retry-on-429, honoring the API's own reset header, and the UI says plainly that an analysis can take longer under load.
The agent was worse than no agent at first. It anchored on a one-venue tag, attributed one venue's review keywords to another, and drifted optimistic. We fixed these with code-side checks and a neutral rating-based verdict rather than longer prompts.
Parameters accepted is not parameters applied. On this model a fixed seed is what makes repeated requests identical, while temperature made no visible difference. We tested it instead of assuming.
Cross-domain seeding. Seeding by tag alone returns either the tag's global audience or generic city culture ("korean_fried_chicken" in New York gives The New Yorker and MoMA). Seeding with the matched venues returns their regulars' tastes: The Infatuation, Eater, Master of None, 2 Dope Queens. We also dropped a "trending cuisine" idea after finding that /v2/trending doesn't support the place type.
Quota. One analysis takes about 4.4 Gemini requests, so the free tier covers roughly 110 analyses a day. Caching, retries and the deterministic fallback keep the app useful past that.
Accomplishments that we're proud of Every fact in the app is traceable to a live Qloo call, and every claim the agent makes links back to the fact behind it. There is no mock data. The cross-domain step is the part that most clearly could not exist without Qloo's graph. And we kept the scope honest: Qloo has no foot-traffic, sales or menu-price data, so the tool never claims any, and it says it's not a fit for food trucks, where footfall and permits decide the outcome.
What we learned "The API gives you a graph" and "we use the graph" are different claims. Projecting a taste signal across domains, seeded by real venues, is what makes the Qloo dependency real. We also learned to verify rather than assume: rate limits by reading headers, data availability by testing entity types live, and model behaviour by measuring it. Code that checks citations can prove a claim is traceable, but not that the reasoning is right, so the UI invites the user to open each fact.
What's next for Dish-Market Fit Advisor Tighter fact checks (numbers and venue names in a sentence must appear in the facts cited); a gap-analysis feature comparing a venue's current menu with what the surrounding audience gravitates toward, using Qloo's compare_audiences and entity_tags workflows; saved analysis history; and an MCP server so other agents can call the analysis directly. If the key's rate limits are raised, city comparisons can grow beyond today's practical limit.
Log in or sign up for Devpost to join the conversation.