HouseFull

Fill the room with fans you don't have yet: a Qloo-powered campaign agent for promoters, venues and artist teams, plus a taste-matched gig guide for fans.

Comment

Inspiration

A show at 40% sold three weeks out is a familiar problem for every promoter, venue and artist team. The usual fix is more ads to the same people: the artist's existing fans and their lookalikes. Most of them have already seen the show and decided.

The people who would actually fill the room are one step out: fans of artists next to the headliner, who live within reach of the venue and simply haven't heard about this show. Qloo's taste graph describes exactly that neighborhood of taste, so we asked: can an agent turn it into a campaign a small team could run today, and learn from what happens?

What it does

HouseFull is a Qloo-powered campaign agent for live music. Pick a booked show (any artist, any venue in New York, New Orleans or Los Angeles, or straight from Ticketmaster) and in about a minute you get a campaign brief:

  • New audiences: three taste-based groups beyond the core fans, each with reasons linked to the Qloo call they came from.
  • Where they live and how far: neighborhoods where that taste over-indexes (not just where people live), with transit or drive time to the venue. In New Orleans, the cities visitors travel from.
  • How to reach them: podcasts, TV shows and brands each audience loves, plus three ad variants per audience, checked by a critic.
  • Opening acts, partner bars and record stores, a street-team route, and a day-by-day countdown.
  • Show night in New York: competing shows, subway disruptions, and a getting-home plan (best late-night train, suggested walking route).
  • Results and re-plan: check in clicks and sales (or upload a Meta Ads export). HouseFull shifts budget to what converts, adds "more like the winners" from Qloo, pauses what doesn't work, and explains every change in a new version.
  • After the show: a two-minute anonymous survey. The artists attendees tick place them in an audience, so organizers see which new audiences loved the night and would come back, with no tracking. An audience its attendees loved isn't paused just because its ads cost more.

Each team gets its own workspace: promoters see every show and what needs attention; venues see their on-sale calendar, who the room draws and local partners; artist teams compare new fans city by city. Every workspace can Ask questions answered only from its own briefs, and has Outreach: contact details for the places, acts and podcasts in its briefs, with a drafted email for each.

For fans, Tonight is a gig guide: live music and jazz clubs open now, ranked by the artists you love. Rate the shows you went to and your picks get sharper.

How we built it

Qloo decides; the language model only writes and checks.

  1. Resolve and profile: /search resolves the artist; /v2/insights with urn:tag gives the core fans' taste.
  2. The next ring: taste-adjacent artists from insights, clustered into three audiences (Gemini only names them).
  3. Where they are: per-audience Qloo heatmaps on geohash-6 cells. Raw heatmap affinity mostly tracks how busy an area is, so we divide by a city-wide nightlife baseline. For each cell, with P the percentile rank over the cells both heatmaps share:

lift = (P_audience + 0.05) / (P_baseline + 0.05)

Cells are snapped to neighborhoods by area, weighted by P_baseline × share, and joined with travel times from a GTFS transit graph (or drive times in LA).

  1. Channels, partners, openers: insights for podcasts, TV, brands and places near the venue; openers use a popularity cap and explainability so they bring new fans rather than headliners' fans.
  2. Writer and critic: Gemini Pro writes the copy. A deterministic critic then requires every claim to cite a Qloo call made in this run, every number to appear in the facts, and no mention of age, gender, ethnicity, religion or sexuality. One model review follows; a failed critique gets one rewrite and never fails the run.
  3. Live and resumable: each run executes inside the request that streams it (SSE), writing an ordered event log to Postgres, so any instance can replay it.

Stack: a pnpm + Turborepo monorepo. Next.js 16 / React 19 / Tailwind 4 / MapLibre on Vercel; NestJS 12 on Google Cloud Run; Gemini on Vertex AI; Postgres 17 with PostGIS and pgRouting on Supabase (with a 1.27-million-edge OpenStreetMap walking graph of NYC); Clerk organizations as workspaces; Ticketmaster, MTA and NYC Open Data; and an MCP server so AI assistants can use the same tools.

Challenges we ran into

  • Heatmaps that only showed population. Our probe found raw heatmap affinity correlated with plain popularity at r ≈ 0.99. Dividing by a baseline brought it to r ≈ 0.07, real taste signal. The same bias appeared in artist recommendations, so Tonight scores acts as affinity − 0.5 × popularity (both scaled): a club act close to your taste can beat a stadium act that's merely compatible.
  • Probing the hackathon API. Locality boundaries returned errors, so we moved everything to geohash cells, and we mapped which parameters each endpoint actually accepts before building on them.
  • Sourced claims vs. fluent copy. The critic flagged artist names like TV Girl and Men I Trust as trait mentions until we masked known names; numbers such as "shift 30% of budget" had to count as advice, not claims.
  • Latency. Default model "thinking" made early runs take ~3 minutes; capping it brought a fresh plan to about a minute, and finished demo runs replay instantly.
  • Messy real-world data. MTA alerts name lines, not stops (so we only surface live line-wide delays); Qloo opening hours are sometimes wrong (the page says to check); Ticketmaster's "music" category includes musicals and drag brunches, which we filter out.
  • Production surprises. Deleting a workspace mid-run crashed the API through an unhandled database error (now caught and tested), and Supabase exposes every table through its REST API by default (we enabled row-level security and revoked access).

Accomplishments that we're proud of

  • Every claim is traceable: each reason in a brief links to the Qloo call behind it, and a With and without Qloo view shows what the taste data adds.
  • A closed loop: plan → run → results → re-plan → post-show survey, where taste (not tracking) attributes attendees to audiences.
  • One engine, four products: dashboards for promoters, venues and artist teams, plus a gig guide for fans.
  • Responsible by design: audiences are taste, never traits; safety data is context for promoters only and never ranks people; fans' location never leaves the browser.
  • Live and tested: deployed on Vercel, Cloud Run and Supabase, with unit and integration tests and a full end-to-end suite covering every flow, including sign-in.

What we learned

  • Taste data is most useful when you remove popularity from it; otherwise every map is a population map and every recommendation is a hit list.
  • Let the model write, not decide. Keeping Gemini to naming, copy and review made the output checkable and much easier to trust.
  • Small teams need the next action, not a dashboard: a countdown step for today, a drafted email, a QR code for the venue screens.
  • Feedback is the product. A plan that learns from sales and from how the night felt is worth more than a perfect first plan.

What's next for HouseFull

  • Ticketing and ad-platform sync, so results arrive automatically instead of by CSV.
  • More cities, and a venue season planner that suggests which dates and acts suit the room.
  • Connect Spotify or Apple Music on Tonight, so fans get picks without typing artists.
  • Shared budgets and caching across instances, and organization webhooks for clean workspace deletion.
  • Partner deals that close the loop: tracked offers with nearby bars and record stores, so venues and promoters can see which partnerships sell tickets.

Built With

Share this project:

Updates

Submission history