Inspiration

A Japanese café that is a hit in Tokyo can't just copy-paste itself into Hyderabad. Menus, ambience and price points that work in one place can miss in another, and "Hyderabad" isn't one culture. Gachibowli, Madhapur and Jubilee Hills each feel different. Expansion teams still do this research by hand across maps, listings and gut feeling. We wanted an agent that translates cultural preferences, not languages, and that is honest about how much the data can actually tell you.

What it does

You describe a brand (for example Hikari, a Tokyo matcha café), give it a few taste seeds (Muji, Blue Bottle Coffee, Spirited Away, Haruki Murakami), pick a target city and candidate neighbourhoods. CultureCompiler then:

  • resolves the seeds in Qloo's taste graph and finds the places near each neighbourhood (optionally restricted to a venue category such as cafés),
  • scores every place twice, once with the brand's taste and once with generic mainstream taste, and compares areas by the paired difference,
  • returns a recommendation card, the closest "peer places" to study, and menu / ambience / price cues, each linked to the Qloo evidence behind it,
  • says plainly when areas can't be told apart, and then gives a clearly labelled tie-break pilot suggestion instead of pretending to have a winner.

How we built it

CultureCompiler is a rule-based agent built on Qloo's taste graph. For each request it:

  1. Resolves the brand's taste seeds (brands, people, movies, books and more) into Qloo entities, plus a set of generic mainstream seeds as a control.
  2. Probes each neighbourhood with Qloo's place search using a point and radius, optionally restricted to a venue category through /v2/tags. If a circle returns too little data, it widens step by step and finally falls back to the whole city, always labelling the level actually used.
  3. Compares brand taste with generic taste on the same places. Each place is scored under both, and the area score is the average difference with its standard error. Two areas tie if they differ by less than two combined standard errors.
  4. Builds the recommendation and ideas: a pilot-area card, the closest peer places, and menu, ambience and price cues, plus city-level channel signals.
  5. Verifies every idea: it must cite evidence that exists in the run, and every number must be traceable to the data.

Stack: Python standard library only (no dependencies), a single-page vanilla JavaScript front end, Docker, and Render for hosting. The Qloo key lives only in a server environment variable, and the demo has per-visitor rate limiting.

Challenges we ran into

We tested against the real API early and our first design failed. Qloo's raw affinity scores were almost flat across neighbourhoods (about 0.80 to 0.82), and generic brands scored higher than our brand's seeds, so our first "lift" number was negative everywhere. With a café filter the brand and generic queries returned the very same places, so comparing the lists told us nothing either. Scoring each place against itself fixed that. Other problems we hit and fixed: hotels showing up as "cafés", payment and accessibility tags showing up as "menu cues", a category tag ("Fashion") that existed but matched zero places, and a 62-second analysis that dropped to about 12 seconds with concurrent calls.

Accomplishments that we're proud of

  • We tested on the real Qloo API early and changed the design when it failed. Our first scoring idea broke on live data, and we replaced it with a per-place comparison that actually separates brand taste from generic taste.
  • Honest by design. When neighbourhoods can't be told apart statistically, the app shows a tie and gives a clearly labelled tie-break pilot suggestion, instead of faking a ranking. City-level fallback data is never passed off as neighbourhood insight.
  • Every claim is traceable. Each idea cites the Qloo evidence behind it, and a verifier rejects anything it can't trace. Across our live test runs, no generated claims were rejected, and the verifier's tests fail if it is deliberately broken.
  • It works beyond the demo example. We tested it live on a Tokyo café entering Hyderabad, a café brand in Mumbai, and a fashion brand with 8 mixed seed types (brands, people, a book, a TV show, a podcast).
  • Fast and robust. A full live analysis went from about 62 seconds to about 12 seconds with concurrent calls. It handles bad inputs with clear errors, category tags that match nothing, rate limiting, and sparse data.
  • A complete, public product. A live demo on Render, an open-source repo (MIT), 59 automated tests, and no third-party dependencies.

What we learned

Testing with real data early changed the design completely. Honest uncertainty (ties, evidence-confidence labels, a limits section) makes the product more useful, not less. Taste affinity is not demand, so every output is framed as a hypothesis to test with a pop-up, not a forecast.

What's next

What's next for CultureCompiler

Add optional rent, footfall and competition data, a map view, and validation against real store outcomes. Today the output is cultural alignment only and does not predict sales or profit.

Built With

Share this project:

Updates

Submission history