Pulse

One-line Summary

Pulse turns live web search, events, local listings, and search momentum into trustworthy nightlife recommendations for where to go right now.

Inspiration

Planning a night out is strangely fragmented. Maps can tell us what exists, ticketing sites can tell us what is scheduled, social posts can hint at what people are talking about, and search trends can reveal sudden momentum—but no single source answers the question people actually have: Where is the energy tonight?

Static star ratings are especially weak for nightlife. A highly rated club can be unusually quiet tonight, while a smaller bar can suddenly become the place everyone is searching for because of a DJ, trivia night, comedy show, or local event. We built Pulse to combine those signals into one timely, location-aware experience.

What it does

Pulse lets someone search a city or neighborhood, choose a nightlife category and time window, and receive a ranked set of current venues and events. It uses SerpApi to retrieve structured Google event and local-place results, compare city-qualified venue searches through Google Trends, and find indexed community evidence from Reddit and Instagram. Pulse then resolves duplicate references to the same real-world place and calculates a comparative heat signal using both overall interest and momentum.

The experience includes:

• Search by city or neighborhood, category, and time window.
• All-nightlife discovery across bars, clubs, restaurants, live music, comedy, trivia, karaoke, and shows.
• Time-aware filtering for tonight, this weekend, this week, and open-now nightlife after midnight.
• A comparative heat meter that accounts for established popularity and sudden search acceleration.
• A neighborhood heat map with interactive venue pins, zooming, and panning.
• Detail cards with hours, location, current event timing, and an official or best-available website link.
• Clerk authentication and a Neon-backed saved-venue experience with city filters and personalized ordering based on saved-venue engagement.
• A refreshable catalog of 5,100 venues across 50 major U.S. cities plus Brooklyn, used to supplement missing static details without inventing information.

How we built it

The production web application is built with Next.js, React, and TypeScript and deployed on Vercel. Server-side API routes keep the SerpApi key private and coordinate a staged retrieval pipeline:

1. Google Search provides structured event results for the requested place and time.
2. Google Local provides structured venue details, ratings, hours, websites, and coordinates.
3. Entity-resolution logic merges events and venue records that refer to the same place.
4. Google Trends compares up to five city-qualified candidates and measures both current interest and change from recent baseline.
5. A city-qualified Google search finds indexed Reddit and Instagram evidence.
6. Pulse combines comparative interest, momentum, venue quality, freshness, and source agreement into a transparent heat score.

Results appear after the primary searches finish, while trend and community enrichment updates the ranking in the background. Requests are coalesced and cached to reduce latency and protect the limited API budget. A separate OpenStreetMap-derived catalog supplies cited static venue information when live results omit hours, coordinates, or official websites.

Authentication is handled by Clerk. Saved venues and interaction counters are stored in Neon Postgres. Anonymous recommendation telemetry is strictly opt-in and preserves the exact context and feature snapshot needed for later model training.

The separate Python ML repository implements the longer-term recommendation architecture: an explicit Markov Decision Process, an embedding-based actor with twin critics, dynamic candidate matching, reward and discounted-return processing, and an offline TD3+BC-style trainer. The live product intentionally continues using the explainable web-hype policy until real consented trajectories and off-policy evaluation can establish that a learned policy is safe and better.

Challenges we ran into

The hardest problem was identity resolution. An event listing, a local result, and a social mention may use different names for the same venue. We combined normalized names with venue context and geographic proximity, while deliberately preventing similarly named places in different locations from borrowing one another’s signals.

Location ambiguity was another major challenge. Queries such as “The Blond” can retrieve unrelated results, so every evidence and trend query is qualified with the requested city, for example “The Blond New York NY.”

Time was more complicated than a normal event filter. At 2:00 AM on Saturday, someone using Pulse usually means “where can I go now,” not “what is happening Saturday evening.” We created a 7:00 AM nightlife-day boundary and reject venues marked closed, opening tomorrow, or reopening on another weekday.

Google Trends also limits comparisons to five terms, so we first use prominence within the current city search to select the strongest comparison set. Missing trend data receives a neutral signal rather than a fabricated value. We applied the same principle to missing hours and websites: unknown information stays unknown or becomes a clearly labeled city-qualified search link.

Finally, we had to balance fresh data with a small SerpApi allowance. We parallelized independent searches, split primary discovery from optional enrichment, coalesced identical in-flight requests, and created the offline venue catalog without using SerpApi calls.

Accomplishments that we're proud of

• Built a working, deployed full-stack product rather than a static prototype.
• Integrated multiple SerpApi result types into one coherent recommendation experience.
• Made heat comparative within each search, so results remain meaningful even in lower-volume cities.
• Modeled both sustained interest and sudden momentum instead of treating raw popularity as the whole story.
• Built a 5,100-venue, source-attributed U.S. catalog with no invented hours or websites.
• Added location-aware entity resolution, overnight timing logic, interactive heat maps, authentication, saved venues, and city filtering.
• Created a privacy-conscious behavior schema designed for future offline reinforcement learning.
• Implemented the MDP, embedding actor, twin critics, reward processing, and TD3+BC training foundation in a separate ML repository without pretending that synthetic training results are production performance.

What we learned

We learned that trustworthy recommendation systems begin with retrieval and data quality, not just a sophisticated model. Fresh signals are only useful when they are attached to the correct place, interpreted in the correct time window, and compared against an appropriate local set.

We also learned that uncertainty should be a product feature. Neutral defaults, explicit fallback states, source attribution, and honest missing-data labels create a better user experience than confident-looking fabricated values.

From the ML side, we learned why nightlife is naturally sequential: the best recommendation depends on where someone is in their evening and what happened after earlier suggestions. We also learned why deploying reinforcement learning before collecting trustworthy behavior probabilities and performing off-policy evaluation would be unsafe. The responsible path is to log consented trajectories first, validate offline, and only then enable limited exploration.

What's next for Pulse

Next, we will convert consented interaction events into versioned state-action-reward-next-state trajectories, implement importance-sampling and doubly robust off-policy evaluation, and add safety slices for city, category, time, and new-user cohorts. Once a candidate policy passes those gates, the ML service will expose a ranking endpoint and support a small, reversible rollout against the current web-hype baseline.

We also plan to add durable cross-instance caching and rate limiting, richer preference onboarding, confirmed-visit feedback, multi-stop night planning, notification timing, transit-aware sequencing, and broader event-source coverage. The business opportunity is a consumer discovery product with optional venue promotion and ticketing partnerships that remain clearly separated from the organic heat signal.

How We Used AI

Pulse combines real-time retrieval, entity matching, feature engineering, and recommendation modeling. Its current production policy uses live structured web signals to generate an explainable ranking. Its next-stage ML system represents each venue as an embedding and treats recommendations as sequential decisions in an MDP, allowing the system to eventually optimize for a successful night rather than a single click.

How We Used Codex

Codex helped turn the concept into two deployable repositories. It assisted with the Next.js interface, SerpApi request design, entity-resolution and heat-ranking logic, overnight timing rules, map interaction, authentication, Neon schemas, privacy-aware telemetry, venue-catalog tooling, and the Python actor-critic foundation. It was also used to debug production issues, inspect data-quality failures, validate the MDP contract, and keep the current product honest about the boundary between its live heuristic policy and its not-yet-promoted learned policy.

Architecture

Browser
  ├── Next.js discovery UI
  ├── Clerk authentication
  └── Interactive recommendation map
        │
        ▼
Vercel API routes
  ├── SerpApi Google Search → current events
  ├── SerpApi Google Local → venue details
  ├── Entity resolution + catalog enrichment
  ├── SerpApi Google Trends → interest + momentum
  └── Indexed Reddit/Instagram evidence
        │
        ├── Explainable web-hype ranking → UI
        └── Consented interactions → Neon Postgres
                                      │
                                      ▼
                         Offline RL training repository
                         MDP → TD3+BC candidate → OPE gate

Testing Instructions

1. Open the public demo.
2. Search for a city or neighborhood and choose a category and time window.
3. Select Find the pulse and wait for the primary cards to appear and refine.
4. Open View heat map, then zoom, pan, and select a venue pin.
5. Open a recommendation’s details and verify its time, location, website link, and like control.
6. Log in, save venues from multiple searches, and verify the Saved carousel and city filters.
7. Select See all and verify that the same city filter controls the vertical saved list.

ML checks:

cd pulse-recommender
PYTHONPATH=src python -m unittest discover -s tests -p 'test_mdp.py'
ruff check .

Public Demo Link

https://pulse-web-lac.vercel.app/

Public Repository Links

• Web application: https://github.com/vapeyproductions/pulse-web
• ML recommendation system: https://github.com/vapeyproductions/pulse-recommender

Demo Video

• YouTube or Vimeo URL: TODO — required by Devpost
• Downloadable original MP4 backup: TODO — required custom field

Screenshot Shot List

1. Brooklyn default recommendations with the horizontal carousel and heat meters.
2. A category/time search with the interactive neighborhood heat map open.
3. A crisp recommendation detail popup showing hours and website access.
4. The authenticated Saved carousel with city pills.
5. The vertical saved-venue page filtered to one city.

Submission Readiness Notes

• The public demo and two public repository URLs are known.
• The Devpost project exists but was still an empty draft when checked at 12:47 PM ET on September 3, 2026.
• Devpost requires a demo video and a downloadable backup of the original video.
• The web application’s latest local commit must be pushed after GitHub authentication completes.

Known Limitations

• The learned RL policy is implemented as an offline foundation but is not used for production ranking yet.
• The current cache is process-local and should be replaced by a durable shared cache before high-volume use.
• Some source records do not publish hours, official websites, or coordinates; Pulse does not fabricate them.
• Google Trends enrichment is limited to five directly compared candidates per request.
• Behavior logs still require a trajectory-building pipeline before they can train the actor-critic model.

Built With

• python
• serpapi