The Problem

During an emergency, getting help should not depend on having a smartphone, installing an application, or having mobile internet.

Many emergency-response solutions assume reliable internet connectivity and modern smartphones. In low-connectivity environments, this creates a serious access gap: a person may have a basic mobile phone and cellular coverage but still be unable to use an internet-based emergency application.

We built RescueHacks to explore a different approach: an emergency-response system that starts with the simplest communication channel available on almost every mobile network — USSD.

What We Built

RescueHacks is an AI-assisted emergency-response platform that allows a person to report an emergency through USSD and routes the incident through an automated response pipeline.

The current prototype follows this flow:

Citizen → USSD → Backend → AI Classification → Priority Engine → Database → WhatsApp Alert → Responder Dashboard

A citizen selects the emergency type, provides a description and location, and receives confirmation that the incident has been received.

The backend then creates a structured incident, analyzes the emergency description using AI, assigns a severity and priority score, stores the incident, and sends an alert to a responder.

Responders can monitor incidents through a dedicated dashboard and update the incident lifecycle from:

Pending → Accepted → En Route → Reached → Resolved

Why AI?

AI is used where it provides practical value rather than being added as a decorative feature.

The emergency description is analyzed to identify the likely emergency category, estimate severity, generate a concise responder-oriented summary, and assist the priority engine.

For example, a description such as:

"A person collapsed and is not responding."

can be classified as a potentially critical medical emergency and prioritized accordingly.

The system also includes deterministic fallback logic so that emergency processing does not completely depend on the availability of an AI service.

Designing for the Future

We also designed RescueHacks around a future physical emergency device.

The planned device consists of an ESP32, GSM connectivity, GPS, an emergency button, buzzer, status indicators, and a battery.

Because we currently do not have access to the physical components, this part of the project is represented through a hardware design, firmware, and a software-based IoT device simulator.

The simulator sends emergency events through the same backend used by the USSD system.

This demonstrates an important architectural principle:

Different emergency input devices can use the same response infrastructure.

A future physical panic button, for example, would not require a separate emergency-response platform. It would simply become another source of incidents.

Engineering Approach

RescueHacks combines several areas of engineering:

  • USSD telecommunications
  • Backend/API development
  • Artificial intelligence
  • Database engineering
  • Web application development
  • Automated notifications
  • Embedded-system architecture
  • IoT system design

The project was designed around a real-world constraint: how can emergency access remain useful when internet connectivity and device capabilities are limited?

What We Learned

Building RescueHacks taught us that the difficult part of an emergency system is not simply receiving an emergency request. The system must handle the complete lifecycle reliably.

We therefore focused on validation, structured incident data, AI failure handling, priority logic, responder state transitions, notification delivery, and a unified architecture for future hardware integration.

We also learned the importance of designing for the actual constraints of the environment rather than assuming that every user has access to the latest technology.

Current Limitations

RescueHacks is a prototype and has not been deployed for real emergency response.

The WhatsApp notification and USSD integrations are being demonstrated using test/sandbox infrastructure. The physical emergency device has not been fabricated and is represented by a simulation and hardware design.

The system is therefore intended for demonstration and research purposes, not as a replacement for official emergency services.

Future Development

Future versions could integrate:

  • Physical emergency devices
  • GPS-based automatic location acquisition
  • SMS fallback
  • Voice and local-language interaction
  • Responder geolocation
  • Automated responder assignment
  • Offline-first field applications
  • Integration with official emergency-response organizations

Our long-term objective is to make emergency access more resilient by allowing multiple communication and device technologies to connect to one response infrastructure.

Built With

Share this project:

Updates

Submission history