Pulse

Pulse shows real-time local conditions — wait times, road hazards, and crowd-reported signals — so you know before you go. Real intelligence, for everyone, not just big chains.

Comment

Pulse — Devpost Submission Draft

Copy each section into the matching Devpost field. Sections marked [PERSONALIZE] have a placeholder — swap in your actual specifics before submitting.

Tagline

Real-time local conditions — wait times, hazards, and crowd signals for the places you actually go.

Inspiration

[PERSONALIZE — the frustration should be a specific real moment, not this generic version]

It came from a familiar situation: showing up somewhere — a shop, a clinic, a gas station — and having no idea how long the wait would actually be, or whether it was even worth going in the first place. Big chains solve this with wait-time apps and live status boards; small local businesses and everyday spots almost never do. We wanted something that gave anyone — not just big companies — a way to share and see real-time conditions for the places around them: how busy it is, whether a road nearby is jammed or blocked, whether a signal's out. That's Pulse.

What it does

Pulse shows live local conditions on a map:

  • Wait times & live crowd counts at nearby shops, clinics, and gas stations, reported by the people actually there
  • Business-owner self-reporting — a verified owner can post their own shop's status directly, no guessing required
  • Road & signal reports — hazards, closures, jams, and traffic signal outages, crowd-confirmed by nearby users
  • Real analytics — busiest times and busiest areas, computed from actual check-in and report history, not fabricated data
  • Directions with live traffic warnings pulled from real user reports, not just static routing
  • Full account system — signup with email verification, guest mode, personalization (theme, map style, saved places), all in 8 languages

How we built it

  • Frontend: a single static index.html — vanilla HTML/CSS/JS, no framework, no build step — using Leaflet.js for the interactive map
  • Backend: a Cloudflare Worker (worker/src/index.js) exposing a JSON REST API
  • Database: Cloudflare D1 (SQLite-compatible), storing users, location reports, check-ins, and owner claims
  • Auth: custom-built — PBKDF2-SHA256 password hashing via the native Web Crypto API, bearer-token sessions, 6-digit email verification codes
  • Maps & data: OpenStreetMap, CARTO, and Esri ArcGIS tiles; Nominatim for geocoding; Overpass API for nearby-places data; Open-Meteo for weather/air quality; OpenRouteService for turn-by-turn directions; Resend for verification emails
  • Deployment: Cloudflare Workers/Pages, entirely serverless

Challenges we ran into

The hardest part was the authentication system. We built it from scratch rather than reaching for a third-party auth provider: PBKDF2 password hashing implemented directly with the native Web Crypto API (no external crypto library), bearer tokens instead of cookies (since the frontend and API live on different *.workers.dev subdomains and cookies don't cross that boundary cleanly), and a 6-digit email verification flow wired through Resend. Getting the token handling right — issuing, validating, and expiring sessions correctly on a Worker with no persistent server memory between requests — took real iteration, especially making sure the verified-owner check on business-update permissions couldn't be bypassed or spoofed.

Accomplishments that we're proud of

  • A fully custom auth system built without any third-party auth service, running entirely on Cloudflare's edge
  • Real, non-fabricated analytics — busiest times/areas are computed from actual usage history, not hardcoded or randomly generated
  • 8-language support across the entire interface
  • A verified-ownership system so business status updates can't be spoofed by random visitors

What we learned

[PERSONALIZE — add anything specific to your experience]

Building auth and real-time data flows on Cloudflare Workers meant working within a stateless, edge-first model rather than a traditional always-on backend — which shaped a lot of the architecture decisions, especially around session handling and D1 query patterns.

What's next for Pulse

  • Refreshing "Nearby Places" data as the map is panned, not just on initial load
  • Expanding beyond .workers.dev to a custom domain
  • Deeper analytics for business owners (trends over time, not just current busiest windows)
  • Real-time traffic data integration, budget permitting

Built With

cloudflare-workers, cloudflare-d1, leaflet, javascript, html, css, openstreetmap, openrouteservice, resend, web-crypto-api

Track

Community Resource Matching — Pulse lets local businesses self-report real-time capacity/status (directly paralleling the track's shelter/food-pantry capacity-reporting example) and helps people find real-time availability at the everyday places they rely on, not just emergency resources.

AI disclosure

AI coding assistants (Claude) were used throughout development — architecture decisions, writing the backend API and database schema, building the frontend UI, implementing the auth system and i18n, and debugging — with the team directing requirements, testing, and final decisions. [PERSONALIZE — adjust the split to match reality before submitting]

Links

Built With

Share this project:

Updates

Submission history