Case study · Built by Jason
How I built The Bar Galaxy: a sourced map of who worked behind which bars.
- 1,372 people, 2,876 venues, 1,566 sourced career stops, 7,634 award records
- 4,288 prerendered static pages, every claim citation-backed
- Ethics policy enforced by a pre-deploy gate, not by copy
- Now available for awards-body partnership, industry publication, or white-label in another craft
The Bar Galaxy was a sourced, crowdsource-ready map of who worked behind which bars in the cocktail industry. It ran at thebargalaxy.com from 2025 to September 2026. As of the archive date it holds 1,372 people, 2,876 venues, 1,566 documented career stops, 195 documented connections, and 7,634 award records, all keyed to published sources. This page is the full case study: what I built, what worked, why I froze it, and how to bring it back.
What it was
A map of bar careers built only from published sources. Search a bartender, see the documented overlap. Search a venue, see the lineage of who worked there and where they came from. Cross-reference the awards: World's 50 Best, North America's 50 Best, Spirited Awards, Speed Rack. Every claim on every page carries a citation. Blanks stay blank. Guesses are not allowed.
The thesis: the bar industry runs on lineage and word of mouth, and there was no sourced, ethical, browsable version of that lineage that respected the people in it.
What I built
The whole thing. Solo. Shipped end-to-end.
- The dataset: 1,372 people, 2,876 venues, 1,566 sourced career stops, 195 documented professional connections, 7,634 award records. Every row keyed to a published source. Every claim carries evidence.
- The static site: 4,288 prerendered HTML pages, one per person, venue, city, and award list. Fraunces and Inter typography, dark navy and cream palette, mobile-first. Loads fast. Indexes clean.
- The pipeline: eight-step build (research merge, awards merge, cleanup, canonical cities, dedupe, policy check, prerender, deploy). Idempotent. Reproducible from source data.
- The backend: a single Deno edge function on Supabase, roughly 1,400 lines, running 22 routes for reads, writes, moderation, one-click owner decisions, and audit logging.
- The moderation system: contributions publish immediately with a byline. One first-hand objection or two ordinary objections pulls the row back down. Anything touching an opted-out record or reading like an allegation is held for a human and never renders.
- The one-click decide flow: signed, expiring, single-purpose links Jason could tap from his inbox to accept, reject, or mark contacted, with an append-only audit log and a hashed IP on every decision.
- The nightly digest cron: a job that stayed silent when nothing needed a human and spoke up only for complaints, reports, and claims. Silence was the success case.
- The ethics policy: dead appear as initials only. Two withheld people are removed from the dataset entirely over industry misconduct. No portraits of real people, ever. No press-article photos. Only emails typed into a form by the person themselves. The policy is enforced by a pre-deploy check that must exit clean before any push.
What it demonstrated
This is the part that matters for anyone thinking about hiring me or building with me.
I can build a real data product without inventing facts. Every claim is sourced. Blanks stay blank. Certainty scores are tagged. A pre-deploy policy gate refuses to ship if the ethics rules are violated. That discipline is unusual, and it is buildable.
I can handle a live moderation queue ethically. Contributions publish fast, get pulled fast when contested, and never render when the target has opted out. The system runs itself 99% of the time and only asks a human when a human is actually needed.
I can ship a static site that indexes cleanly at scale. 4,288 prerendered pages, one per entity, with per-page canonical URLs, per-page JSON-LD, per-page OG images, and an accurate sitemap. No SPA-only fallbacks. No client-side render for content Google needs.
I can enforce a policy at the data layer, not just in copy. The `apply_policy.py` check is the gate. If a deceased person's name appears in full, if a withheld person appears anywhere, if a portrait photo lands in the assets tree, the deploy blocks. The rules are not vibes. They are code.
I can design a decision system that trusts the operator over the audience. One-click, signed, expiring inbox links let one person moderate a live crowdsource system from their phone in seconds, with a full audit trail, without ever pasting a secret token into an email or a URL.
Why I froze it
The product worked. The dataset is clean. The pipeline is idempotent. The moderation system is honest. What did not happen was distribution.
Being honest about what happened: a 720-hour contribution-tracking window returned zero on every counter. Nobody outside me added, corrected, reported, or claimed anything in a full month. The bottleneck was never features or data quality. The bottleneck was that the bar industry did not, on its own, walk up and start editing.
I could have spent the next six months on distribution: outreach to venues, seeding awards partnerships, running a manual claims campaign, building the multi-location model, wiring the admin editor. Instead I froze it read-only. The dataset stays browsable at thebargalaxy.com. Contributions, corrections, reports, and claims are closed. The nightly cron is off. The operating cost is nearly zero.
The freeze was a discipline call, not a failure of the product. The product did what I designed it to do. It surfaced the lineage. What it did not do was find the crowd fast enough for me to justify running the crowd-facing system as an ongoing venture.
What lives on
- The read-only site stays live at thebargalaxy.com. All 4,288 pages continue to serve. The dataset is browsable. The sitemap still indexes.
- The dataset (seed.json plus the awards records) is preserved. Available on request for research or partnership use.
- The ethics policy patterns (deceased-as-initials, withheld list enforced by a pre-deploy gate, source-required-per-claim, one-click signed decision links with hashed audit log) are the templates I now use on every data project I build for clients.
- The prerender pipeline and the sourced-only build discipline power how I think about the BuildoutFeed dataset, the KMS Connect operator dashboards, and every future data product I ship.
How to bring it back
The site is dormant, not dead. Everything is preserved: the seed.json dataset, the 4,288 prerendered pages, the eight-step build pipeline, the Supabase edge function, the moderation queue, the ethics policy gate, the nightly silent digest, the one-click decide flow. If the right partner shows up, it comes back online.
What that looks like:
- Awards-body sponsor: World's 50 Best, Spirited Awards, Speed Rack, Tales of the Cocktail, or a category award wants a co-branded lineage explorer for their winners and nominees. I run it. You own the surface. Estimated deploy time: 2-3 weeks to swap branding, integrate your award roster, and open the moderation queue for your community.
- Investor stake in the data asset: the sourced dataset itself has value as a research surface, a talent-scouting tool, and a licensing property. Minority position or outright buyout of the dataset with continued operating stewardship. Terms open.
- Industry publication partnership: a spirits or hospitality publication wants the lineage graph as a research tool for their reporters, or as a reader-facing directory. I stand it up under your masthead. Same engine, your brand, your editorial oversight.
- White-label to another industry: same career-lineage engine applied to chefs, sommeliers, DJs, tattoo artists, session musicians, or any craft with a documented apprenticeship trail. Scoped as a KMS Connect build. Estimated deploy time: 3-4 weeks to re-theme, re-seed, and reconfigure the source ingest.
- Custom build on the pattern: you want the underlying architecture (sourced-only ingest, policy-enforced prerender, one-click signed moderation, silent-by-default digest) applied to a different problem. Not a career map, a different data product built on the same bones. Scoped as a KMS Connect engagement.
If any of these fit: tell me what you are running.
What it means for what I ship next
I build data products that tell the truth about what is sourced and what is not. I ship live static sites at scale that index cleanly. I enforce ethics at the deploy gate, not in the copy. I design moderation flows that let one person run a live crowd system without leaking secrets or blowing up trust.
If you have a data-quality problem, an ethical-scraping problem, or a lineage-and-provenance problem in your industry, and you want it solved with a real system instead of another dashboard subscription: tell me what you are running.
Get this for your operation
Built by Jason is the productized version.
This is what Built by Jason does when it is deployed against a real operation. Text me if you want to see how it fits yours.