Sahaaya Relay

Inspiration

During floods, landslides, and other disasters, communication networks often become unreliable exactly when people need them most.

A survivor may still have a working smartphone, but without mobile data or a stable signal, their emergency request can remain trapped on that device. At the same time, responders may receive incomplete messages, repeated reports, unclear locations, and conflicting information.

This led us to one question:

What if an emergency request could continue moving even when the network could not?

That question became Sahaaya Relay.

Sahaaya means “help,” and the project is built around a simple idea: when infrastructure cannot carry an emergency message, people can carry it.

What it does

Sahaaya Relay is an offline-first emergency coordination platform designed for floods, landslides, major outages, and other situations where continuous connectivity cannot be guaranteed.

A survivor can create an emergency request using Malayalam or English and include important details such as:

What happened
Number of people affected
Elderly people, children, injuries, or medical dependencies
Approximate location
Required resources
Supporting photographs or voice notes

The request is converted into a compact, structured Aid Packet.

The Aid Packet is stored locally on the device using IndexedDB, meaning the request can survive page refreshes and temporary loss of connectivity. Each packet receives a unique identifier and an SHA-256 integrity hash that helps detect unexpected changes to its contents.

The packet can then be prepared for QR-based relay. A nearby volunteer device can carry the essential request information until connectivity becomes available again.

Once the packet reaches a connected response point, Sahaaya demonstrates how the information can appear inside a responder command centre, where a human responder can review the report, verify its urgency, assign resources, and track the incident through a response timeline.

The core communication model is:

Report offline → Store locally → Relay through people → Synchronize when connected → Coordinate response

A real-world scenario

Our judge-facing demonstration is based on a flood emergency in Panamaram, Wayanad.

A Malayalam report states that four people are trapped inside a flooded house. Two of them are elderly, one requires insulin, and the water is continuing to rise.

Sahaaya transforms the report into an Aid Packet containing:

Flood rescue request
Four people affected
Two elderly residents
Insulin required
Rescue boat required
Medical kit required
Approximate location
Integrity and relay information

This allows responders to understand the essential context quickly instead of working through fragmented messages.

How we built it

We built Sahaaya Relay as a mobile-first Progressive Web Application using:

Next.js and React
TypeScript
Tailwind CSS
Framer Motion
IndexedDB and Dexie
Zod validation
Web Crypto API
QR generation and local decoding tools
Vitest and Playwright

The application is divided into several experiences:

Survivor request flow

A stress-aware, mobile-friendly form guides the user through the emergency type, description, people affected, vulnerabilities, resource requirements, location, and evidence.

Drafts are stored locally so users do not lose their progress after refreshing or temporarily leaving the page.

Aid Packet engine

The submitted information is validated, structured, serialized, and sealed as an Aid Packet. The packet receives a unique ID and integrity hash before being stored locally.

Relay Vault

The Relay Vault displays all packets available on the device, including their emergency category, location, integrity state, transfer size, relay history, and synchronization status.

QR relay preparation

Sahaaya generates compact QR transfer data from the essential packet information. Camera and image-based decoding are processed locally without uploading QR images to an external service.

Responder command centre

The command centre presents a prototype operations view with incident priority, location context, required resources, human verification controls, assignments, and a response timeline.

Judge Mode

We created a deterministic Judge Mode that explains the entire product journey in approximately 90 seconds. It uses the real local packet engine while simulating selected backend and responder actions for presentation reliability.

Challenges we faced

One of the biggest challenges was designing for a situation where internet access cannot be assumed.

Most modern applications are built around constant cloud connectivity. Sahaaya required us to think differently about local persistence, refresh recovery, offline behaviour, packet size, and how data could move between devices.

Another challenge was balancing technical complexity with emergency usability. A powerful system is not useful if a person under stress cannot understand it. We therefore focused heavily on large touch targets, clear instructions, accessible contrast, mobile responsiveness, and reducing unnecessary decisions.

QR reliability also required careful consideration. Emergency information must remain compact enough to transfer while preserving important context. Full photographs and audio files cannot always fit into a compact QR transfer, so the prototype clearly separates essential relay data from media that remains stored locally.

We also had to remain honest about what was real and what was simulated. Local persistence, Aid Packet generation, integrity hashing, QR preparation, and the Relay Vault are implemented. Cloud synchronization, live AI processing, official emergency-service integration, and real dispatch operations remain future development areas.

Accomplishments we are proud of

We are proud that Sahaaya Relay became more than a visual concept.

The prototype includes a working offline-first request flow, persistent local storage, integrity-protected Aid Packets, QR relay preparation, a Relay Vault, mobile optimization, an operational command-centre prototype, and a complete Judge Mode.

We are also proud of the product’s focus on responsible technology.

AI is positioned as an assistant that can eventually structure, translate, and recommend—not as an authority making irreversible rescue decisions. Critical actions remain visible and human-confirmed.

What we learned

Building Sahaaya Relay taught us that emergency technology must be designed around failure, not perfect conditions.

We learned how to:

Build reliable browser-based offline storage
Design versioned and validated data structures
Use hashing to detect content changes
Prepare compact information for QR transfer
Create interfaces for high-stress situations
Build responsive experiences for small mobile screens
Clearly communicate prototype limitations
Separate human decision-making from automated recommendations

Most importantly, we learned that meaningful innovation is not always about adding more technology. Sometimes it is about helping essential information continue moving when the usual systems stop working.

What’s next for Sahaaya Relay

The next stage would focus on field testing and production readiness.

Future development includes:

Testing live QR transfer across representative Android and iOS devices
Authenticated and idempotent backend synchronization
Malayalam and English speech transcription
Translation with visible confidence scores
Structured incident extraction
Geographic and semantic duplicate-report detection
Responder authentication and role management
Resource availability and live incident maps
Stronger device identity and audit trails
Collaboration with NGOs, relief teams, campuses, and local authorities
Accessibility, privacy, security, and disaster-recovery testing

Sahaaya Relay is currently a hackathon prototype and does not replace official emergency services. However, it demonstrates a different way to think about disaster communication:

When networks fail, help should not stop. Help should still move.