ResQ

Inspiration

During a natural disaster, the people who need help most can lose the ability to ask for it. Cell towers become damaged or congested, calls disconnect, and emergency responders are left working with incomplete information.

We started ResQ with a question: What happens when someone needs emergency help, but a normal 911 call cannot reliably get through?

To understand the problem beyond what we could find online, we spoke with David Jones, an all-hazard emergency responder who worked during Hurricane Helene under the National Incident Management System (NIMS). He explained that one of the hardest parts of disaster response was communication with affected communities and turning incoming information into something responders could actually use.

That changed how we thought about the problem. Getting a message through is only the first step. Once responders receive dozens or hundreds of reports, they also need to understand who needs help, where they are, what they need, and how urgent their situation is.

We built ResQ to address both sides of that problem.

What it does

ResQ is a low-bandwidth emergency communication and Decision Support System (DSS) designed for disasters and degraded networks.

For someone requesting help, ResQ captures their voice message, location, and essential information while reducing the amount of data that needs to cross the network. Voice is recorded as Opus audio at approximately 12 kbps, making each report much smaller than a traditional high-quality audio recording.

For responders, ResQ converts those reports into structured incidents. Each report can be transcribed, translated, categorized, assigned an urgency level, geocoded, and displayed on an interactive map.

Instead of treating emergency reports as disconnected calls, ResQ creates a shared operational view of what is happening across an affected area.

The DSS does not make decisions for responders. It organizes incoming information so responders can make better-informed decisions themselves.

How we built it

ResQ is built as a single Next.js 16 application using the App Router, React 19, TypeScript, and Tailwind CSS 4.

Low-bandwidth communication

We designed the civilian interface around the assumption that connectivity may be weak.

The browser's MediaRecorder API captures voice as compressed Opus audio at approximately 12 kbps. The Web Audio API generates the live waveform and detects periods of silence, while the Web Speech API provides live captions.

Because recording and compression happen on the user's device, ResQ does not need to upload a large raw audio file before reducing its size.

The Geolocation API captures the user's GPS coordinates when available, reducing the need for someone in an emergency to manually explain their location.

AI speech processing

Once a report reaches the server, we process its audio using the open-source Whisper Small model through Hugging Face Transformers.js and ONNX Runtime.

Our pipeline can detect English, Spanish, French, and Mandarin, transcribe the original message, translate it into English, and produce confidence information for the transcription.

FFmpeg converts incoming recordings into the audio format required by Whisper.

This means a responder can receive a structured English report even when the person requesting help speaks another supported language.

Decision Support System

After transcription, ResQ processes the report through our DSS.

We built multilingual keyword-matching and scoring rules that analyze the transcript to identify categories such as medical assistance, food and water, or shelter. The system also identifies the type of disaster and calculates an urgency score.

The original report, transcription, location, classification, urgency information, and audio are then combined into a single incident.

Responders can view these incidents through a Leaflet map powered by OpenStreetMap. GPS coordinates are converted into readable locations using Nominatim, with Google Geocoding available as an optional fallback for spoken addresses.

Our Next.js API routes handle report creation, retrieval, assignment, deletion, and audio streaming. Reports and recordings are stored locally using SQLite.

The result is a pipeline that moves from:

Voice → Compression → Transmission → Transcription → Translation → Classification → Geolocation → Decision Support

Challenges we faced

Our biggest challenge was building around the assumption that the network itself could be unreliable.

Most web applications assume users have enough bandwidth to continuously communicate with a server. We had to think differently. We looked at what could happen directly on the user's device, how small we could make an emergency message, and what information actually needed to be transmitted.

Multilingual speech created another challenge. We needed to detect the language, convert different audio formats, transcribe speech, translate it, and still preserve enough information for a responder to understand the original report.

We also had to determine the role AI should play in emergency decision-making. We did not want ResQ automatically deciding who receives help. Instead, we designed the system as a Decision Support System. AI and our scoring system organize and surface information, while human responders remain responsible for the actual decisions.

Finally, scope was a major challenge. Emergency communication infrastructure is massive, and we were building ResQ during a hackathon. We focused on demonstrating one specific idea: critical emergency information can be compressed for constrained networks and transformed into actionable information once it reaches responders.

What we learned

The biggest thing we learned is that successful emergency communication is not simply about sending a message.

A message has to get through, be understood, and become actionable.

We also learned how different software development becomes when bandwidth is treated as a limited resource. Audio bitrate, local processing, message size, GPS data, transcription, and interface design suddenly become parts of the same problem.

Most importantly, speaking with David changed our development process. Instead of asking whether a feature sounded impressive, we started asking whether it solved a problem that responders or affected communities could realistically face.

That pushed ResQ from being a communication tool toward a complete pipeline connecting people requesting help with the responders making decisions.

What's next

Our current prototype proves the core ResQ workflow. The next step is testing it under simulated low-bandwidth, high-latency, and intermittent network conditions and measuring transmission size, latency, and reliability.

We also want to continue working with emergency responders to improve our urgency model and DSS interface based on real response procedures.

Finally, ResQ currently represents satellite connectivity, including Starlink Direct-to-Cell, as part of the concept rather than an active integration. A future version could investigate how ResQ's compressed emergency packets could work across satellite and other disaster-resilient communication channels when terrestrial networks are unavailable.

ResQ connects two problems that are often treated separately: getting critical information out of a disaster zone and helping responders make sense of it once it arrives.