Rescue

• 

  The dashboard

• 

  Claiming Response

• 

  Request For Help

• 

  Responder Confirming their identity through email OTP or "Magical Link" in order to respond to an incident

• 

  Reporting a new Incident

Inspiration

During natural disasters, traditional communication infrastructure and emergency dispatch lines quickly become overwhelmed. I saw a critical gap: victims need a zero-friction way to request immediate aid without filling out long forms or navigating paywalls, while spontaneous local responders need a clear, unified visual grid to pick up requests without overlapping or hijacking each other's rescue routes. I wanted to build a high-velocity tactical command center that turns chaotic data streams into organized, lifesaving action.

What it does

RescueRoute is a live, real-time mutual aid routing canvas. It splits the crisis management lifecycle into two frictionless flows:

Victims / Civilians: Can access the platform instantly—completely unauthenticated in "Anonymous Mode"—to drop localized crisis markers (Medical, Water/Food, Shelter, Evacuation) onto a map.

Responders: Log in securely via magic link OTP to access a persistent dashboard. They can visually review tickets, track urgency metrics globally, and claim "Open" tickets. Once a ticket is claimed, the interface locks out other responders to avoid coordination chaos, seamlessly flying the map camera down to the exact street coordinates.

How we built it

The platform is built on a modern, high-performance web stack designed for sub-second updates: Frontend: Next.js and React managed with TypeScript to guarantee structural stability, styled with Tailwind CSS, and animated via Framer Motion. Mapping: React-Map-GL (Mapbox/MapLibre) leveraging imperative camera manipulation hooks for smooth, fluid viewport flight transitions. Backend & Database: Supabase (PostgreSQL) handling real-time data synchronization. We implemented custom, idempotent SQL migration scripts utilizing specialized triggers to automate timestamp mutation tracking, and enforced strict Row-Level Security (RLS) policies to protect user states while leaving resource reads entirely public.

Challenges we ran into

Building for real-time synchronization under hackathon constraints brought intense engineering bottlenecks:

Strict Type Contradictions: I ran into severe TypeScript compilation friction where the compiler inferred index path signatures as never contexts due to blank schema templates. We solved this by implementing intermediate cast assertions directly on the client update chains to keep deployment builds moving.

Idempotency Failures: Repeated schema migrations caused database runtime errors when attempting to add existing tables to the logical replication stream (ERROR 42710). I bypassed this by re-architecting the SQL files with PL/pgSQL DO blocks to safely verify publication presence before structural mutations.

Local Network Drops: I hit sudden local DNS resolution dropouts (net::ERR_NAME_NOT_RESOLVED), forcing us to systematically hunt down build cache corruption states, wipe out hidden .next directory trees, and flush local environment configurations to ensure uninterrupted connectivity.

Accomplishments that we're proud of

Bulletproof Database Scripting: We successfully unified isolated SQL statements into a single, production-grade, highly resilient database baseline that can be executed repeatedly on a live instance without crashing.

Sub-Second Map Syncing: Achieving true dual-user reactivity where an anonymous user drops a pin and an authenticated responder sees it pop up on their map instantly without a manual page refresh.

Clean UI Composition: Successfully managing overlay balances—such as keeping the map draggable through wide gap containers while anchoring live statistics and session badges cleanly underneath the top navbar.

What we learned

I learned the immense value of making database files fully idempotent from day one. Relying on simple CREATE blocks breaks pipelines rapidly during continuous integration. We also gained a deep understanding of the subtle complexities of WebGL map viewstate bindings—specifically, how to sync component-controlled layouts with imperative camera controllers (flyTo) without locking up user panning capabilities.

What's next for Rescue

My next immediate step is to integrate a true offline-first cache wrapper using service workers so the map grid remains accessible even during intermittent cellular network degradation. We also plan to integrate routing engines (like OSRM) to automatically calculate the fastest physical path from a responder's current GPS coordinates straight to the center of their claimed rescue tickets.

Built With

• next.js
• openai
• openstreetmap
• react
• supabase