The problem I wanted to solve
Most emergency-alert apps make the same bad assumption: the person in danger has time, privacy, and a working data connection to open an app, unlock their phone, and tap through a UI.
If someone is being followed, robbed, or is in a situation where their phone is visible to a threat, none of that holds. What they do usually have is a phone that can dial a number, even on 2G and with zero data.
That's the idea behind RescueHacks Alert: dial a short USSD code, and an emergency contact gets notified on WhatsApp in real time. No app. No internet requirement on the victim's side. No visible menu that gives away what's happening.
The core design decision: no menu
My first instinct was to build an interactive USSD menu. Dial the code, see a list ("1. Medical, 2. Security, 3. Fire..."), and pick one. Standard USSD UX.
Then I thought about who's actually dialing this. If someone is being confronted, pulling out their phone and having a menu appear on screen is a giveaway. USSD sessions stay visible while they're active.
So I dropped the menu entirely. The emergency type is encoded directly in the digits the person dials with a single, silent action.
*384*23492*1# → Medical
*384*23492*2# → Safety threat
*384*23492*3# → Accident
*384*23492*4# → Disaster
Dial it, and the session ends immediately with no visible confirmation screen. To anyone watching, it looks like a dropped call attempt. Behind the scenes, the backend fires an emergency alert.
For the demo video, I narrated it with a shorter, more realistic-looking code like *911*[1-3]#. A real deployment would use a telecom-issued short code rather than a shared sandbox number. The working prototype runs on Africa's Talking's longer sandbox code above.
Architecture
Victim's phone
│ dials USSD code
▼
Africa's Talking USSD Gateway
│ HTTP callback
▼
AWS Lambda (USSD handler)
│ parses emergency type from dialed digits
▼
Meta WhatsApp Cloud API
│
▼
Emergency contact receives alert on WhatsApp
Everything runs on AWS SAM. API Gateway sits in front of a Lambda function that parses the incoming USSD session and triggers the WhatsApp send.
Where it got interesting: three bugs that taught me more than the happy path
1. The Lambda that "sent" messages that never arrived
Early on, the WhatsApp send was fire-and-forget. I called the send function but didn't wait for it before returning the USSD response. It worked sometimes.
The reason was simple: AWS Lambda freezes the execution environment as soon as it returns a response. If your background async call hasn't finished, it stops. No error. No completion.
The fix was straightforward once I understood it. await the WhatsApp send before returning the USSD response.
2. A WhatsApp template that Meta quietly reclassified
I submitted a message template under the Utility category, which is required for sending outside WhatsApp's 24-hour messaging window.
Meta approved it, then quietly reclassified it as Marketing. Marketing templates require recipient opt-in, which my test number didn't have. The API returned a success status with a valid message ID, but nothing arrived.
The dashboard never made the real reason obvious. I only found the actual category by querying the Meta API directly. For the hackathon deadline, I switched to plain-text messages inside the 24-hour window and documented the template fix for later.
3. A token that worked in testing and silently failed in production
My quick-test access token worked perfectly. The permanent system-user token used by the deployed app returned success but delivered nothing.
Same phone number ID. Same WhatsApp Business Account. Same recipient.
That pointed to a permissions issue rather than a code bug. The system user needed full control of the WhatsApp Business Account, along with the whatsapp_business_messaging permission, before the permanent token worked.
None of these problems were obvious from reading the documentation. They only showed up after building, deploying, and comparing "API says success" with "nothing arrived."
The result
End to end, dialing *384*23492*2# in the Africa's Talking sandbox simulator triggers a WhatsApp emergency alert on the registered contact's phone in real time. No app. No menu. No visible trace on the victim's screen.
What's next
RescueHacks Alert started as a hackathon weekend build. I look forward to
turning it into my final-year Mechatronics Engineering project by adding a physical SOS tracker (ESP32 + GPS + cellular), live location tracking, a responder dashboard, and AI-assisted emergency classification with confidence-scored outputs rather than overclaimed certainty.
That's a much bigger build with real hardware and power-budget constraints, and I'll be documenting the process as it develops.
Built for the RescueHacks hackathon on Devpost. Code, demo video, and submission details: https://devpost.com/software/rescuehacks-alert.
Top comments (0)