SaathiRelay

Create User Profile
Help Required
Home Screen
Help Required Page

Inspiration

Every major disaster follows the same pattern: the earthquake hits, the flood rises, the storm knocks out power — and within minutes the cell towers go down too. Not because they're destroyed, but because tens of thousands of people are trying to call their families at once. In that gap, people who need help and people who could give it are standing blocks apart with no way to find each other. We wanted to build something that doesn't depend on the network staying up — something people already have in their pocket, that works the moment they open it, even if they never get a signal again.

What it does

SaathiRelay is an offline-first Progressive Web App that turns nearby phones into a community emergency relay. People pick one of three roles — Requester, Helper, or Relay node — and the app takes it from there. A Requester can send out a request tagged by type (medical, fire, flood, safety, supplies, other) and priority, optionally attaching GPS coordinates. Helpers nearby see the request appear and can respond with "I can help." Relay nodes forward packets between devices so a request can hop beyond direct range, with a TTL-based hop limit to stop flooding. Everything is stored locally in IndexedDB, the whole app is cached by a service worker, and it's fully accessible — skip links, ARIA live regions, keyboard navigation, high contrast and reduced-motion modes — so it works for people under stress, not just tech-savvy users.

How we built it

SaathiRelay is a dependency-light PWA — no build step, just HTML, CSS, and vanilla JavaScript, so it can be served from anywhere and installed straight from a browser tab.

js/db.js handles all persistence through IndexedDB, so requests, roles, and history survive offline and across reloads.
js/relay.js is the mesh packet relay — it uses the BroadcastChannel API to propagate emergency packets between tabs/devices sharing an origin, with TTL-based hop limiting (max 8 hops) to prevent flood loops.
sw.js is the service worker that pre-caches the app shell so it keeps working with zero connectivity after the first load.
manifest.json makes it installable as a home-screen PWA.
css/styles.css implements the accessibility modes (high contrast, large text, reduced motion) alongside the base theme.
js/app.js ties it together into the Requester/Helper/Relay workflows.

Challenges we ran into

Building for "zero connectivity" meant we couldn't lean on any of the usual crutches — no server round-trips, no cloud database, no push notifications. Getting the service worker to reliably cache everything needed for a true offline reload (and not silently fall back to a network request) took real trial and error. Simulating a real mesh without hardware was another challenge: BroadcastChannel only reaches tabs/devices on the same origin, so we had to be upfront that this is a same-origin relay demo standing in for what a production version would do over Bluetooth LE or Wi-Fi Direct. Designing for accessibility under stress — not just compliance, but genuinely usable by someone panicked, injured, or using assistive tech — pushed us to rethink defaults like font size, contrast, and motion far more than a normal app would.

Accomplishments that we're proud of

A fully offline-capable PWA that installs and runs with zero backend infrastructure.
A working relay simulation with TTL-based hop limiting that mirrors how a real mesh network would need to behave.
Accessibility built in from the start rather than bolted on — skip links, ARIA live regions, and multiple visual modes.
A clear, honest architecture that separates what's real today from what needs real radio hardware to go to production.

What we learned

We learned how much of "the internet" modern web development quietly assumes is there — and how differently you have to design once you take it away. We got hands-on with IndexedDB, service workers, and the BroadcastChannel API as real offline-first tools rather than theoretical browser features. We also learned that accessibility and emergency UX are deeply linked: the same design choices that help a screen-reader user also help someone who's panicking, injured, or has shaking hands.

What's next for SaathiRelay

Real device-to-device mesh via Bluetooth LE or Wi-Fi Direct, replacing the same-origin BroadcastChannel demo with actual cross-device range.
An SMS/USSD fallback gateway so a request can escape the mesh the moment any one node regains connectivity.
End-to-end encryption for request payloads.
Integration with official emergency services (112/911) with clear disclaimers, so SaathiRelay complements rather than replaces them.
Integration of Voice commands and support for Native languages.