MamaAlert — Hackathon Project Write-Up

SDG 3: Good Health

Inspiration

Someone close to me went through a maternal emergency. I won't share the details — but I will say that what almost determined the outcome wasn't the severity of what was happening. It was the time it took for anyone to reach her.

That experience stayed with me.i didn't have to think long about what to build.

I went looking for existing solutions and found tools that required smartphones, app stores, reliable internet, and health literacy. All of which assumed the very infrastructure that rural, low-income, and underserved women simply don't have. The women most likely to face a maternal emergency are also the women least likely to be served by the technology built to help them.

I found the WHO's Three Delays Model — a research-backed framework explaining that most maternal deaths are not caused by untreatable conditions. They are caused by three consecutive failures: delayed decisions, delayed transport, and unprepared facilities. Together, these delays consume hours that women don't have.

That is what MamaAlert is built to collapse.

What It Does

MamaAlert is a community-powered maternal emergency alert system. When a pregnant woman faces a life-threatening situation, she triggers a single SOS — through a PWA tap, a USSD code (*456#), or an SMS keyword. No internet required on her end. No app store. No login.

In under 60 seconds, the system:

Runs a PostGIS geospatial query to find every active volunteer within 5km, sorted by distance
Fires an SMS to all of them simultaneously via Twilio
Starts a 5-minute escalation timer — if no one responds, the radius widens to 10km, then 20km automatically
When the first volunteer replies YES — the patient receives a confirmation SMS, her family emergency contacts receive a status link, and the nearest clinic receives a pre-alert with her name, blood type, risk flags, and estimated arrival time
The alert is only marked resolved when the hospital replies ARRIVED to the pre-alert SMS

Six roles are supported: patient, volunteer, health worker, hospital, family, and NGO admin. Each has a purpose-built interface. The patient sees one button. The volunteer responds by SMS — no app needed. The hospital never logs in at all.

The entire system is a Progressive Web App installed directly from the landing page. No Play Store. No App Store. A health worker installs it on a patient's phone in under 30 seconds at an antenatal care visit.

How I Built It

Built entirely solo over the course of the hackathon.

Frontend: React 18 + Vite + TypeScript (strict mode) + Tailwind CSS + shadcn/ui. The PWA is scoped exclusively to the /sos route — service worker caching, IndexedDB offline queue, and Background Sync apply only to the patient SOS screen. Everything else is a standard website.

Backend: Node.js + Express + TypeScript + Prisma. REST API deployed on Railway.

Database: Supabase (PostgreSQL) with the PostGIS extension enabled. Volunteer and patient locations are stored as GEOGRAPHY(POINT, 4326) columns. The radius query uses a stored PostgreSQL function with ST_DWithin and ST_Distance — returning volunteers sorted nearest-first in a single efficient query.

SMS: Twilio for global SMS and IVR voice confirmation. Africa's Talking for USSD and Africa-region SMS fallback.

Auth: A custom phone-number-only session system. No Supabase Auth, no JWTs, no OTPs. Patients and volunteers are identified by phone number stored in localStorage. Health workers and admins use email + password. Admin self-signup requires a secret access code set via environment variable.

Landing page: Built with Three.js for the WebGL globe, Framer Motion for scroll-triggered animations, and a live death counter calculated from WHO data — one death every 121.8 seconds from page load.

Hosting: Vercel (frontend) + Railway (backend). GitHub Actions for CI/CD.

Total external cost to run the demo: $0.

Challenges I Ran Into

Honestly — everything was hard. But these four were the hardest:

1. PostGIS + Prisma Prisma doesn't natively support PostGIS geography types. Getting ST_DWithin and ST_Distance to work correctly required writing raw SQL stored functions in Supabase and calling them via Prisma's $queryRaw. The coordinate order in PostGIS is longitude first, then latitude — the opposite of what every API and map library returns. Getting this wrong produces no error. It just silently returns zero volunteers within any radius. Caught this in testing when the demo returned no results.

2. Offline queue surviving browser close The Background Sync API is the right tool for queuing a SOS alert when the patient has no signal. But it only works reliably on HTTPS, only on Android Chrome, and the sync event fires in the service worker — completely separate from the React app. Keeping the IndexedDB store schema identical between offline.ts (React) and sw-sos.js (service worker) required careful coordination, and a mismatch would cause the queue to fire but POST malformed data silently.

3. SMS + USSD across two providers Twilio handles global SMS and IVR voice. Africa's Talking handles USSD and serves as the Africa SMS fallback. Both providers use different webhook formats, different authentication schemes, and different response formats. Twilio expects TwiML. Africa's Talking expects plain text with CON or END prefixes. Both hit the same Express server. Managing this without mixing up response formats — especially since both POST to different routes but share the same alert logic — required careful middleware separation.

4. Replacing Supabase Auth entirely The original architecture used Supabase Auth for health workers and admins. Mid-build, I moved to a phone-number-only session model to unify authentication across all roles. This meant removing Supabase Auth from both the client and server, rewriting all RLS policies that used auth.uid(), updating every protected route, and rebuilding the entire sign-up and login flow as a single unified page. Mid-hackathon. While everything else was still being built. That was a rough 12 hours.

Accomplishments That We're Proud Of

The moment that mattered most: a real SMS firing on a real phone in under 60 seconds from a single button tap.

Not a simulation. Not a mock. A Twilio SMS landing on a physical phone — containing the patient's name, location landmark, weeks of pregnancy, and a YES/NO reply instruction — within 60 seconds of the SOS button being pressed. That is the entire point of MamaAlert condensed into one moment, and watching it work for the first time was the most satisfying thing I have built in a long time.

Beyond that: the fact that this runs entirely on free tiers. Supabase free. Twilio trial credit. Vercel free. Railway free starter. A system capable of handling a genuine maternal emergency in rural India costs nothing to deploy. That matters enormously for the NGOs and health systems that would actually use it.

And building all six roles — patient, volunteer, health worker, hospital, family, admin — in a single unified codebase, with one sign-up page, one session model, and purpose-built interfaces for each — solo, in a hackathon window — is something I did not think I could pull off when I started.

What I Learned

The most important thing I learned has nothing to do with code.

Technology's real power is not replacing infrastructure. It is activating the human network that already exists.

Every pregnant woman in rural Maharashtra already has a neighbour with a motorcycle. A retired nurse two streets over. A community health worker who knows her name. The problem is not that these people don't exist. The problem is that they don't get called in time.

MamaAlert does not build hospitals. It does not train doctors. It does not fix roads. It just makes sure that the right person gets a text message at the right moment.

That realisation changed how I think about building for underserved communities. The instinct is always to bring something new. The better instinct is to ask what already exists — and what is preventing it from working.

On the technical side: designing for the most constrained user forces better decisions across the board. Building for a woman with a basic Nokia phone and no internet produced an architecture — SMS-primary, USSD fallback, offline PWA queue — that is more resilient than any smartphone-first system I have built before. The constraints were the design.

What's Next for MamaAlert

Three things, in parallel:

1. Pilot with GNEC's NGO network The immediate next step is a real-world pilot in two or three districts with existing GNEC field partners. Health workers already do antenatal care visits. They already have phones. Adding MamaAlert to their workflow is a 30-second install and a 3-minute patient registration. No new infrastructure required.

2. Open source and self-deployment The full codebase will be open sourced on GitHub with a one-command deployment guide. Any NGO with a technical contact should be able to deploy their own instance for their zone in under an hour. The $0 operating cost on free tiers makes this viable for organisations with no tech budget.

3. Grant applications and health-tech funding USAID Digital Health, Wellcome Trust, and several UN agency digital health funds are realistic targets. MamaAlert's direct alignment with SDG 3.1, its evidence base in the WHO Three Delays Model, and its demonstrated feasibility make it a credible application.

What's missing right now and needs work before real deployment: a more robust volunteer identity verification system, formal clinical validation of the escalation timing with obstetric specialists, IVR voice confirmation fully tested across African carrier networks, and a proper security audit of the phone-number-only auth model.

I am not pretending MamaAlert is finished. But the core works. The SMS fires. The volunteer responds. The clinic prepares. And the architecture can carry what needs to be built on top of it.

That is enough to start.