Lifeline

Inspiration

During disasters, communication often becomes unreliable exactly when people need it most. Cellular towers can go down, internet access can become inconsistent, emergency information can become scattered, and people may not know where to find shelter, supplies, or assistance.

Most emergency apps also assume that users have a stable connection and can easily understand the information being sent to them. We wanted to build something that remained useful across different levels of connectivity while bringing the most important disaster-response tools into one place.

That idea became Lifeline: a Swiss-army-knife disaster communication and coordination platform designed for residents, volunteers, shelters, and emergency coordinators.

What it does

Lifeline allows coordinators to broadcast structured emergency alerts while giving residents a simple way to request help.

Residents can specify what they need, including evacuation, medical assistance, food, water, shelter, or accessibility support. They can include urgency, group size, an approximate location, and additional details without needing to write a long message.

Coordinators receive these requests in a prioritized dashboard where they can acknowledge them, assign a response team, and update the resident with statuses such as assigned, en route, or resolved.

Lifeline adapts to the connection currently available:

With internet access, messages synchronize across long distances through the cloud. If the outside internet fails but devices share a local Wi-Fi network, Lifeline can transfer alerts and requests directly between nearby browsers using WebRTC. If no connection can be established, information is saved locally and can be transferred using QR codes or downloadable relay packets. When connectivity returns, queued information can synchronize automatically.

Lifeline also includes disaster utilities such as SOS and Morse-code signaling, coordinates, offline emergency guides, hazard and resource reporting, accessibility settings, text-to-speech, language support, and cached incident information.

How we built it

We built Lifeline as a responsive web application so it could run directly in Safari or another modern browser without requiring an App Store installation.

The frontend is built with Next.js and deployed through Vercel. Supabase provides cloud data storage and real-time synchronization for alerts, requests, and status updates.

We designed Lifeline around a transport-independent packet system. Alerts, help requests, status changes, and map reports use the same structured format regardless of whether they travel through Supabase, a WebRTC DataChannel, or an offline QR or file relay.

For nearby communication, we used WebRTC DataChannels to create a direct peer-to-peer connection between browsers on the same local Wi-Fi network. QR codes can exchange the connection information needed to establish the local room and can also act as a fallback for manually transferring individual packets.

IndexedDB and offline caching allow the application to preserve received alerts, locally created requests, emergency guides, and other essential information when the network becomes unavailable.

We also designed the interface around stressful conditions: large actions, clear delivery states, minimal navigation, visible connectivity information, and explicit warnings when a request has only been saved locally rather than received by a coordinator.

Challenges we ran into

Our biggest challenge was understanding what phone hardware and browser APIs could realistically do.

We initially explored Bluetooth mesh networking, UWB, Wi-Fi Direct, LoRa, and other communication systems. However, we discovered that an install-free iPhone website cannot access Bluetooth or UWB as a general messaging transport. Bluetooth also would not provide guaranteed long-distance communication, and LoRa would require external radio hardware.

Instead of hiding those limitations, we redesigned Lifeline around multiple honest connectivity levels. Cloud synchronization provides long-distance communication when infrastructure works, WebRTC provides direct nearby communication over local Wi-Fi, and QR or file relay provides a manual store-and-forward fallback during complete isolation.

Another challenge was preventing duplicate or misleading requests. The same packet may arrive through the cloud, a local peer, and a manual relay. We addressed this using unique packet identifiers, local persistence, validation, expiration, and deduplication.

We also had to distinguish technical delivery from real human action. A request being saved, transferred, or accepted by a server does not mean help is coming. Lifeline only displays statuses such as acknowledged or assigned after a coordinator explicitly performs that action.

Accomplishments that we're proud of

We are proud that Lifeline is more than a collection of emergency tools. It creates a complete communication loop:

A coordinator broadcasts an alert. A resident receives clear instructions. The resident submits a structured request. The coordinator acknowledges and assigns it. The resident receives a meaningful status update.

We are also proud of the system’s ability to degrade gracefully. Instead of becoming completely unusable when connectivity changes, Lifeline switches between cloud synchronization, direct local communication, offline storage, and manual relay.

Another major accomplishment was keeping the architecture transport-independent. Future networking methods can be added without rebuilding the alert, request, mapping, and coordination workflows.

Most importantly, we designed Lifeline to communicate its limitations honestly. The application clearly tells users whether information is saved locally, transferred to a nearby peer, synchronized to the server, acknowledged by a coordinator, or assigned to a responder.

What we learned

We learned that disaster technology cannot be designed around perfect conditions. Connectivity is not simply online or offline; it may be intermittent, limited to a building, available only through one device, or restored temporarily.

We also learned that software cannot overcome physical radio limitations by itself. UWB is useful for precise nearby positioning, Bluetooth is limited by range and platform access, and true long-distance outage communication generally requires infrastructure such as LoRa, satellite systems, or temporary emergency networks.

This led us to focus on resilience rather than making unrealistic claims. A strong disaster system should use the best available transport, preserve information when that transport fails, and clearly explain what has and has not been delivered.

We also learned how important interface language becomes during emergencies. Words such as “sent,” “received,” and “assigned” must represent different technical and human events. In a normal application, that distinction may be minor. In an emergency system, it can affect someone’s decisions and safety.

What's next for Lifeline

Our next priority is improving the reliability of local peer-to-peer communication and testing Lifeline across more real devices, browsers, and network configurations.

We also want to expand the incident map with offline basemaps, expiring hazard reports, verified shelters, resource availability, corroboration, and clear trust labels. Community reports must remain useful without presenting incomplete information as guaranteed truth.

Additional planned features include:

Downloadable emergency packages for specific regions Family and group check-ins Volunteer and supply coordination More languages and accessible alert formats Text-to-speech and simplified instructions Better offline maps and survival guides Native iOS and Android applications Background store-and-forward networking Optional integrations with LoRa or Meshtastic gateways UWB-assisted indoor navigation and responder-location tools Connections to official emergency-alert and shelter systems

Our long-term vision is for Lifeline to become a shared disaster operating system that works across households, schools, shelters, community organizations, and response teams.

Help should not disappear with the signal.