Inspiration

Ask a chatbot to plan a crossover event for Phoebe Bridgers fans and it answers A24, in Los Angeles. That's the famous partner and the biggest city, with nothing measured behind either. That's how a lot of real event planning works too: gut feel, a population table, and whoever is already famous.

We wanted the opposite: a planner that finds the partner whose fans actually overlap, the city where that shared audience is actually strongest, and that shows its evidence for every pick. Qloo's taste data made that possible, because it measures what audiences over-index on, not just how many people live somewhere.

What it does

Takeover: type any fanbase, get the event. An artist, a comedian, a podcast, a film, a football club. Takeover:

Finds the crossover partner whose fans over-index on yours. For Phoebe Bridgers, that's PEN15 (98/100 shared audience).
Picks the city where both audiences are strongest together: Seattle, #1 for overlap but only #18 by population.
Chooses the room, an opener and sponsors in that city.
Writes a one-page brief and outreach drafts, with every claim next to its Qloo source.

Solo or crossover, your call. Taylor Swift doesn't need a partner: pick Solo and the plan is built on her own fans.

Tour planner. It turns a fanbase's strongest cities into an editable, day-by-day tour: shows, travel days from real distances, rest days, and a venue, support act, sponsor and contacts per stop. Type changes in plain English ("swap Portland for Boulder, add a rest day after Seattle"), then export to CSV, a calendar file or PDF.

More tools, all on Qloo data: Fan overlap, Brand match, Venue booker, City explorer, Lineup optimizer, City pages and a daily guessing game.

For teams, after signing in with Google: shared workspaces, rosters, an outreach pipeline, market watch, a sponsorship matchmaker, outcome tracking and a public API.

A built-in "LLM only" toggle shows what a chatbot guesses with no taste data, so the difference Qloo makes is one click away.

How we built it

Qloo Taste AI API for every partner, city, venue, opener, sponsor and audience profile: insights, heatmaps, demographics and search.
A scoring engine in plain TypeScript (lib/engine) computes every number: partner affinity relative to its category with a popularity guard, combined city heat from both audiences' heatmaps mapped onto GeoNames cities, and venue and sponsor ranking.
A 7-step agent streams each step to the browser as it runs, along with the exact Qloo request behind it.
Gemini writes only the prose, using placeholders like {city}. Code fills in the names and numbers, and a sanitiser strips any number, date or price the model slips in.
Next.js 16, React 19, TypeScript and Tailwind 4, from a Claude Design handoff.
Upstash Redis for the Qloo cache, rate limits and the daily AI budget. Neon Postgres with Drizzle for workspaces. Auth.js with Google sign-in. Deployed on Vercel.

Challenges we ran into

Keeping the AI honest. Language models love to invent capacities, dates and percentages. We made it structural: the model never sees a number it could repeat as fact, a sanitiser removes anything that slips through, and unknowns render as "to confirm with the promoter."
Mega-stars beat everyone. Raw affinity always pointed at whoever was most famous. We score affinity relative to each category, with a popularity guard, so the partner is a genuine fit, not just the biggest name.
Geography bugs. Merging suburbs into metros quietly merged San Diego into Tijuana and El Paso into Ciudad Juárez, across borders. We caught it testing on real Qloo data and fixed it so merges stay inside one country.
Big payloads. A US heatmap is 1–3 MB of JSON. Batched cache reads were timing out, so we measured every Redis call and changed how reads are cached and sent.
Free-tier AI limits. Letting the model choose every step took about six AI calls per plan. We moved the steps into code and made it one AI call per plan, with automatic fallback across Gemini models, and template wording if all of them fail.
Letting AI edit a tour safely. The tour planner's plain-English edits become structured operations that code validates. A date or number is accepted only if it appears in what the user typed, and every city must be real.

Accomplishments that we're proud of

Every number on screen is traceable to a Qloo call and a formula you can read in the repo. The in-app "How it works" page shows those formulas with the exact numbers the code uses.
Non-obvious answers that hold up: Seattle at #18 by population, Boston for Taylor Swift. These are cities a population table wouldn't pick.
Nothing fails silently. Ambiguous names get a picker, typos get "did you mean", thin data widens to regional overlap, and a missing venue moves to the nearest city. Every fallback is labelled.
Real engineering discipline: 500+ unit tests, 17 end-to-end suites, and CI that runs lint, typecheck, the production build, a secret scan and a check that blocks sample data in production.
A full product, not a demo: 25 features, from a daily game to a team pipeline, live at takeover-fawn.vercel.app.

What we learned

The best use of an LLM here was the smallest one. Code makes the decisions, Qloo provides the evidence, and the model writes clear sentences around them. That makes the system cheaper, faster and trustworthy.
"Where do fans over-index" is a different question from "where do people live", and it gives far more interesting answers.
Testing on real data finds the real bugs. Our cross-border city bug and the cache timeouts never showed up on sample data.

What's next for Takeover

Venue size that matches the act, so a stadium artist gets arenas rather than clubs.
Plugging in real ticketing and CRM data alongside Qloo signal (the "Your data" upload already supports this) to predict sell-through.
More markets beyond the US, UK, Canada, Australia and Western Europe.
Email sign-in and team invites on a custom domain, plus one-click booking requests that are still never sent without the user's explicit click.
A promoter-facing API, so agencies can run Takeover inside their own tools.