CrowdPulse

Inspiration

Our inspiration for this project came from our shared love for music, as well as our shared thought that most live events treat the audience as strictly noise. We wanted a system where the energy of the crowd is used as an input signal all without the clutter of installing an app or having to make an account.

What it does

Crowdpulse is a live-session stack for all kinds of events. Attendees join, pick a mood, vote on tracks, and optionally tip a track with a Solana devnet boost. The stage view shows a current queue of songs, energy of the crowd, and visuals that update in real time. The host view controls the run, analytics, Spotify playback, and Gemini AI DJ suggestions. Audience votes and moods are validated on the server and persisted in TigerData, and they are broadcast over WebSockets so every screen stays in sync. Host actions are gated by Auth0.

How we built it

For the web layer, we used a mix of React and Vite for the join/stage/host/player screens. For the server layer, we used Express and WebSocket for the authoritative session state. For the data layer, we used TigerData (specifically Postgres/Timescale) using write-then-apply, dedup, and replay. For the AI layer, we used the Gemini API for recommendations with strict zod validation. For the chain layer, we used Solana devnet for the boosts for songs, which is verified on-chain before counting. For the authentication layer we used Auth0 JWT and host: permissions. For the deployment layer we used Vultr and Caddy/systemd tooling.

Challenges we ran into

We had extensive difficulty when initializing third-party resources, specifically Auth0. In our project, only the host should be able to control the music; hence, it was problematic when we had difficulty when logins failed with unauthorized_client until we found the cause in the Auth0 dashboard settings.

We also had difficulties with Spotify playback. For instance, Spotify doesn’t export tempo or energy data, so Gemini had to complete these tasks. Highlights mode is also forced to cut the song externally through time-synced lyrics (LRCLIB) and Gemini, since it cannot examine the audio.

Lastly, we had difficulty with Gemini occasionally providing incorrect data. For example, it would ignore a harsh condition the user requested or output the wrong number of songs.

Accomplishments that we're proud of

More than anything, we are proud of building a fully functioning product from several interfaces working in conjunction: the attendee phones, the host dashboard, and the projector screen. As a result, it's a product that could realistically be used at real events as it stands, and it runs smoothly.

Specifically, we are very proud of the versatility of CrowdPulse. Highlights mode makes CrowdPulse ideal for loud settings with fast-changing music, while the regular mode works well for quieter, more mellow settings.

We are also proud of how we incorporated the tools we were provided. Auth0 gives CrowdPulse real security, so only the host can control the music. Solana introduces in-app "boosts" that, while running on devnet for now, show how CrowdPulse could generate genuine revenue. TigerData is crucial for saving every event, so a session can recover fully after a crash or restart.

What we learned

A big part of what we learned during this project is how difficult it is to make several services work together, even though the payoff is so high. For instance, we faced an issue where logging in to Spotify would sign the host out of Auth0.

Another critical lesson was learning to adapt to platform limits. At times, we faced restrictions we hadn't foreseen that seemed to block our ideas entirely. For example, Spotify wouldn't give us tempo data or access to its audio. However, we were able to build around these problems and find workarounds we never would have expected.

What's next for CrowdPulse

Next for CrowdPulse, we plan on strengthening the deployed demo path through increasing cell phone testing, doing full load tests, and live Auth0/Gemini/boost evidence on the public url. We also plan to implement better crowd-to-music loops through a more robust auto play system and better playlist curation UX. Finally, we want to ensure that we have venue ready packaging by testing multi-session ops, stronger rate limits, and clearer public performance. Additionally, we would have to get Spotify licensing guidance beyond just demoing for the hackathon.

Built With

• auth0
• caddy
• express.js
• gemini
• jwt
• node.js
• phantom
• playwright
• postgresql
• react
• solana
• spotify
• systemd
• tigerdata
• timescaledb
• typescript
• vite
• vitest
• vultr
• websockets
• zod