PULSE
Crowd coordination through collective play for large-scale venues.
Year
2025
Status
Deployed
Stack
Next.js · TypeScript · Firebase · Google Maps · Cloud Run · Vitest · Playwright
Problem
Venue crowd management systems fail consistently: they treat people like traffic. Generic PA announcements have no personal incentive attached. Each person hears the same instruction and waits for someone else to move first. Congestion persists even when the announcement is correct. This is the whistle problem: coordination without incentive doesn't coordinate.
Why it matters
Large sporting venues concentrate crowd density at predictable friction points — entry gates at match start, concession stands during intervals, exit corridors at full time. Injuries and bottlenecks at these points are not random: they are predictable outcomes of coordination failure. Solving the incentive problem converts a recurring safety challenge into a tractable product problem.
Approach
PULSE reframes redistribution as collective play. Every attendee is assigned to a team at venue entry based on seating section. Movement is no longer framed as compliance — it's contribution to your team's spread score. Challenges are issued in real time: reach a target spread percentage across venue zones before the other teams. Nobody receives a generic instruction. Everyone receives a personal reason to act now. The behavioral insight: social feedback creates movement that authority cannot. Watching your team's spread score update in real time gives immediate, personal feedback that a PA announcement structurally cannot.
Architecture
Next.js 16 App Router + TypeScript. Firebase Authentication (Google Sign-In and anonymous for low-friction entry). Firebase Firestore for real-time challenge state, team locations, and leaderboard via onSnapshot listeners. Google Maps Platform with Visualization API for a live satellite heatmap of crowd density across 8 venue zones. Deployed to Google Cloud Run on asia-south1 with Cloud Build CI/CD. Full test suite: Vitest for unit and component tests, Playwright for E2E. The Challenge Recommender is rule-based. It analyses current zone occupancy across 8 zones, reviews team performance history from the last 5 challenges, factors in event timing (early / halftime / late), and outputs recommended zones, target spread, duration, and plain-English reasoning for the ops operator to review before issuing.
System flow
Attendee scans in at venue entry→Assigned to team by seating section→Venue ops creates challenge (manual or Recommender-assisted)→Challenge broadcast to all teams via Firestore→Teams see spread score update in real time→First team to hit target spread wins reward→Venue ops sees live heatmap update throughout
Execution Context
Built in one week for PromptWars Virtual. First Google Cloud Run deployment — secrets management via Secret Manager, Cloud Build pipeline configuration, Docker image sizing, and region selection all required debugging under time pressure. The deployment surface was the steepest learning curve of the build.
Result
Placed 145th out of 3,000+ submissions across 11,000 participants at PromptWars Virtual — top 5%.
Tradeoffs
Anonymous Firebase Auth enables frictionless entry but loses team assignment if the user closes and reopens the browser. A production deployment needs a lightweight persistent identity layer. The rule-based Recommender doesn't learn from outcomes — ML trained on historical crowd data is the correct production upgrade, but requires data that doesn't exist at build time.
Learnings
Cloud Run deployment taught me that infrastructure complexity compounds non-linearly — each additional service adds an integration surface that interacts with every other. The behavioral premise held through every design decision: social incentives outperform authority in coordination problems. Every feature that didn't serve the incentive loop got cut.