ResPulse

Disasters bury people AND the network they'd call for help. So we made survivors the network: one tap turns any phone into an offline SOS beacon, relayed phone to phone until rescue.

Comment

Inspiration

During disasters, the first systems to fail are often the ones people depend on most: cellular networks, internet access, power, and reliable information. Yet many people still have a phone with Bluetooth, local storage, sensors, and some remaining battery.

The devastating earthquakes that struck northern Venezuela on June 24, 2026, made this problem feel especially urgent. The magnitude 7.2 and 7.5 earthquakes caused widespread destruction and disrupted essential services, leaving communities facing an ongoing humanitarian and public-health emergency. The disaster demonstrated how quickly conventional communication and response infrastructure can become damaged, overwhelmed, or inaccessible. (USGS, PAHO/WHO)

We were inspired by the people affected, the rescuers working under extreme conditions, and the challenge of locating and supporting survivors when normal communication channels are unavailable.

We built ResPulse to make the phones already within a community useful even when the network is down. Our goal was to preserve the essentials during an emergency: a person’s distress signal, their situation and accessibility needs, practical offline guidance, and a way for nearby devices and responders to help carry that signal toward safety.

We built ResPulse to make those phones useful even when the network is unavailable. Our goal was to preserve the essentials during an emergency: a person’s distress signal, their situation and accessibility needs, practical offline guidance, and a way for nearby responders to find them.

What it does

ResPulse is an offline-first disaster-response platform for rescuees, nearby relay devices, field responders, and command teams.

A person can activate an SOS beacon that broadcasts a compact distress packet over Bluetooth Low Energy. Nearby phones can relay the signal, allowing it to travel beyond the original device’s range without cellular service. Responders can identify, prioritize, claim, and close incidents, while observations synchronize with the backend when connectivity returns.

The mobile app also provides:

  • Offline maps, shelters, hazards, saved waypoints, and field guides
  • Household, medical, mobility, and accessibility context stored securely on the device
  • An offline rescue assistant with hazard-specific guidance and reviewed regional sources
  • Battery-aware emergency and power-saving modes
  • Clear distinctions between direct and relayed signals

The mobile app also includes hazard-specific emergency flows for hurricanes, floods, wildfire smoke, earthquakes, heat, cold, medical injuries, poisoning, burns, and lost-outdoors situations. The assistant remembers structured details such as location, injuries, group size, pets, supplies, battery, signal, and changing hazards so follow-up responses remain relevant.

Regional preparedness packs allow users to download reviewed guides, local emergency contacts, shelters, hazards, map data, route information, and RAG resources before connectivity is lost. The app also provides route-confidence labels so users can distinguish verified offline routes from compass-only guidance and unknown terrain.

The responder experience includes direct and relayed signal confidence, offline claim and rescue actions, conflict handling, and an audit trail. The command dashboard can create deterministic rescue SITREPs, rank safe destinations using distance, status, capacity, accessibility, and hazards, and display route overlays for operators.

When connectivity is available, a command dashboard displays active incidents, public-safety information, shelters, hazards, and responder activity in a shared operational view.

How we built it

We built ResPulse as a three-part platform:

  • A Flutter mobile app for rescuees, relay devices, and responders
  • A FastAPI backend for synchronization, content distribution, incident reconciliation, and real-time updates
  • A React and TypeScript command dashboard with Leaflet-based mapping

The mobile app stores critical state locally with Drift and SQLite. This allows SOS sessions, relay queues, maps, guides, and responder actions to survive connectivity loss or an app restart.

For device-to-device communication, we designed a versioned 16-byte BLE packet containing a privacy-preserving beacon identity, sequence number, relay limit, triage flags, battery level, timestamp, and integrity check. Each relay deduplicates packets and reduces their remaining relay count to prevent loops.

The backend uses SQLAlchemy and Alembic to maintain an authoritative incident lifecycle. WebSockets deliver live updates to the dashboard, while REST endpoints handle beacon observations, responder actions, regional content, and public-safety data.

The chatbot combines a local Gemma 3 1B model with EmbeddingGemma 300M retrieval embeddings. Structured context extraction, hazard metadata, source filtering, contradiction detection, and conservative fallback rules help prevent unrelated emergency guidance from being mixed into the response.

We also used GPT-5.6 through Codex as an engineering collaborator across Flutter, Python, TypeScript, database migrations, testing, and documentation. However, AI is not allowed to dispatch responders or determine authoritative rescue outcomes.

GPT-5.6 through Codex was also used as an engineering collaborator to inspect the repository, implement the mobile, backend, and dashboard features, investigate bugs, improve the RAG pipeline, create database migrations, write regression tests, and update the project documentation.

Challenges we ran into

The hardest challenge was building for an environment where successful network communication cannot be assumed. Every important action needed to work locally first and synchronize safely later.

BLE introduced another set of constraints. Advertisement space is extremely limited, mobile operating systems restrict background radio activity, and a successful advertising call does not prove that another phone received the packet. We had to manage duplicates, relay loops, sequence-number wraparound, changing Bluetooth addresses, and the difference between a direct signal and one forwarded by another device.

Reconciling offline responder actions was also difficult. Two responders may claim the same incident without knowing about each other, or an old relay packet may arrive after a rescue has already been completed. We addressed this by giving the backend authority over conflicts and making rescued, cancelled, and expired incidents terminal.

Privacy required careful tradeoffs. Nearby devices must be able to relay an emergency signal, but they should not receive someone’s name or detailed medical history. ResPulse broadcasts only compact triage flags while keeping sensitive household information in secure device storage.

Finally, offline AI required strong safety boundaries. Emergency guidance must remain conservative, attributed, and honest about uncertainty. The assistant prioritizes reviewed regional material and clearly labels general fallback guidance instead of presenting generated advice as professional instruction.

Accomplishments that we're proud of

We are especially proud that ResPulse is more than a collection of emergency screens. It has an end-to-end, offline-first workflow.

We implemented multi-device BLE relay logic, durable local queues, duplicate suppression, privacy-preserving beacon identities, and an authoritative rescue lifecycle. Our simulated radio tests demonstrate that a distress signal can cross multi-phone relay chains while respecting relay limits.

We also built a unified experience spanning the person requesting help, the responder in the field, and the command operator coordinating the broader response. Accessibility needs, power constraints, signal provenance, and offline operation are treated as core product requirements rather than optional additions.

Most importantly, the system is honest about its limits. It distinguishes simulations from physical radio validation, relayed signals from direct sightings, verified routes from compass-only guidance, and reviewed sources from general advice.

What we learned

We learned that offline-first architecture is not simply caching an online application. It requires treating the local device as the immediate source of truth and designing synchronization as a later reconciliation process.

We also learned that transmitting less information can create a stronger system. A compact, carefully versioned BLE protocol is easier to validate, relay, and protect than attempting to broadcast complete rescue profiles.

Emergency technology must communicate uncertainty as clearly as it communicates data. Knowing whether a signal is direct, whether a route is verified, or whether guidance comes from a reviewed source can be just as important as the recommendation itself.

Finally, we learned that reliability depends on testing failure paths, not only successful demos. Dropped advertisements, conflicting responder actions, missing sensors, stale observations, unavailable providers, and low-battery conditions all shaped the product.

What's next for ResPulse

Our next priority is physical-device validation across Android and iOS. We want to test real-world BLE range, obstacles, interference, background restrictions, and battery consumption using multi-phone relay chains.

We also plan to replace one-shot relay advertisements with bounded, randomized rebroadcast campaigns, improve the Android background radio worker, and report scanning and advertising capabilities separately so users always understand what their device can actually do.

Beyond radio reliability, we want to add downloadable offline map tiles and verified routing graphs, expand reviewed regional emergency-content packs, strengthen responder identity and deployment security, and conduct pilots with emergency-management professionals and accessibility advocates.

The long-term vision is for ResPulse to become a resilient communication layer that communities can prepare before a disaster, so when infrastructure disappears, nearby people, responders, and the phones already around them can still work together.

Built With

  • fastapi
  • flutter
  • gemini-3
  • react-vite
  • supabase
Share this project:

Updates