Zindua

Detect. Alert. Act.

Comment

What Inspired Me

The Horn of Africa has some of the world's most sophisticated early warning infrastructure. ICPAC issues seasonal forecasts. GDACS monitors active disasters in near real-time. FEWS NET tracks food insecurity across the region. The data exists, is updated regularly, and is freely available.

And yet, in 2024, the Kenya Meteorological Department issued more than five heavy rainfall advisories between March and May — giving government and humanitarian organisations adequate time to act. Over 250 people still died in the floods that followed.

The warnings existed. The communities didn't receive them in time, in a language they understood, with a clear instruction on what to do next.

That gap — between institutional early warning and community early action — is what Zindua was built to close. The name itself captures the mission: zindua is Swahili for "to trigger, to activate, to wake up." A flood bulletin published in English in Nairobi means nothing to a pastoralist community in Turkana if it never reaches them, or reaches them in words they cannot act on. Zindua is the missing link — the system that takes what institutions already know and turns it into the moment a community actually moves.

What it does

Zindua is a last-mile early warning relay platform for the IGAD region. It monitors two real-time disaster data sources — GDACS and Open-Meteo — and when a hazard is detected, it does something no existing system does: it rewrites the alert into plain, spoken language, translates it into five regional languages, sends it directly to community focal points via SMS, and waits for a reply.

Those replies — 1 for Received, 2 for Acting, 3 for Need Help — are the feedback loop that makes Zindua different. Every alert on the coordinator dashboard shows a live confirmation rate: how many focal points acknowledged the warning, how many are already acting, and which ones are requesting assistance. Unresolved escalations are flagged as overdue after six hours. Coordinators can mark escalations resolved with a note describing the action taken — creating an audit trail of response, not just warning.

Early warning without confirmed receipt is just broadcasting. Zindua makes it a conversation.

How we built it

Zindua runs as a five-layer pipeline, triggered every three hours by GitHub Actions:

Layer 1 — Ingestion. Two public APIs are polled on each run: GDACS for active disasters (floods, droughts, wildfires, cyclones) across the IGAD bounding box, and Open-Meteo for 7-day precipitation and temperature forecasts at 14 monitored locations across Kenya, Ethiopia, Somalia, South Sudan, Uganda, Djibouti, Eritrea, and Sudan. Each alert is normalised into a consistent internal schema — regardless of source — and deduplicated using Upstash Redis before being saved to a Neon Postgres database. The deduplication layer is critical: the pipeline runs far more frequently than alerts are issued, so without it, the same drought warning would be processed dozens of times.

Layer 2 — AI Translation. Raw alert content is technical, jargon-heavy, and written for analysts. A community elder in Marsabit cannot act on "Minor impact for agricultural drought in 488,851 km² — IPC Phase 2 conditions persisting." The translation engine runs in two stages: Google Gemini Flash 2.0 rewrites the alert into plain spoken English under 120 characters, with a single concrete recommended action. Google Translate then converts that clean English output into Swahili, Somali, Amharic, and Oromo. The result is five actionable SMS messages per alert, each under 160 characters, each ending with something a focal point can do immediately.

Layer 3 — Relay. The relay engine matches each translated alert to registered community focal points by country code and preferred language, then dispatches SMS via Africa's Talking. A notification record is created before each send, and updated with delivery status after — so there is always a paper trail, even when sends fail.

Layer 4 — Feedback. Every SMS ends with reply instructions in the focal point's language. Replies are received via Africa's Talking webhook and recorded against the notification, generating a community confirmation score per alert. Reply code 3 — Need Help — triggers an escalation that surfaces immediately in the coordinator dashboard.

Layer 5 — Dashboard. A real-time Next.js dashboard gives coordinators a Leaflet map of active alerts, a live alert feed with per-alert confirmation progress bars, a focal point management panel with full CRUD, and an escalation queue with resolution workflow — including coordinator notes, quick-action shortcuts, and overdue detection.

Challenges we ran into

1. The last-mile data problem

I spent significant time attempting to integrate three humanitarian data sources before finding ones that actually worked.

FEWS NET — a gold-standard food security data source — had locked their alerts API behind authentication, and key endpoints returned 500 errors even with valid credentials. Their Data Warehouse API, while documented, serves static reference data and PDF reports, not queryable live alerts.

ReliefWeb required an approved application name for API access, a process that took days and ultimately blocked testing entirely during the hackathon window.

ICPAC's East Africa Hazards Watch — the most relevant source geographically — serves its data as raster and vector map tiles for a web viewer, with no documented public REST API for structured alert ingestion.

I ultimately replaced all three with GDACS, which has a clean REST API, a Swagger-documented endpoint structure, and real-time disaster coverage across the IGAD region. The lesson was hard-earned: in the humanitarian data space, the quality of public documentation is inversely proportional to the importance of the data source.

2. SMS delivery in sandbox

Africa's Talking's sandbox environment only delivers to phone numbers registered as testers in the sandbox dashboard — making it impossible to demonstrate real community relay without physical phones registered in advance. Rather than present a broken demo, I built two workarounds: a simulation endpoint (/api/simulate/reply) that triggers reply codes directly in the database exactly as the real webhook would, and a Focal Points panel in the dashboard with a dedicated Simulate tab where coordinators can fire reply codes per alert or per focal point during a demo. The confirmation rates update live, escalations fire, overdue flags appear — the full feedback loop is demonstrable without a single real SMS being sent.

3. The Translation Quality Problem

Google Translate's Oromo support is limited, producing translations that are grammatically awkward in ways that would undermine trust among Oromo-speaking focal points. The two-stage pipeline helped significantly — because Gemini produces short, simple, grammatically clean source sentences, the downstream translation has less to distort. Even so, Oromo remains a weak point. For production, this would require either a fine-tuned regional language model or partnership with a specialist in Cushitic language NLP.

4. Serverless Cron Problems

Vercel's free tier restricts cron jobs to once per day — insufficient for a near-real-time early warning system where a flood can develop in hours. I migrated pipeline orchestration to GitHub Actions, which runs every three hours at no cost, provides full execution logs per run, supports manual triggering from the repository UI, and sends email alerts on failure. It was an architectural improvement I hadn't anticipated.

5. Financial Problems

Every infrastructure decision in Zindua was shaped by financial constraints, and each one taught me something:

Vercel Cron → GitHub Actions: Serverless scheduling has real limits. Moving to a CI/CD tool as a cron runner is a legitimate production pattern, not just a workaround. Official Google Translate API → @vitalets/google-translate-api: GCP requires billing activation even for free-tier usage. The unofficial package works reliably for a prototype, with a clear upgrade path to the official API when funding is available. Africa's Talking live SMS → Sandbox + Simulation: The sandbox constraint forced me to build a simulation layer that is, arguably, more useful for demos than live SMS would have been. Being unable to buy the real thing made the demo story better.

Constraints are a design tool if you let them be.

Accomplishments that I'm proud of

The ingestion pipeline. Pulling from two structurally different APIs, normalising them into a single schema, deduplicating across runs, and saving reliably to Postgres — all running automatically every three hours without manual intervention — felt like building a real piece of infrastructure, not a hackathon project.

The translation engine. Watching a raw GDACS drought alert — dense, technical, written for an analyst in Geneva — transform into a 148-character Swahili SMS ending with a concrete action for a Kenyan elder was the moment Zindua felt real. That pipeline working end-to-end, across five languages, is what I'm most proud of technically.

The feedback loop. Building a system where a community member's reply — a single digit sent from a feature phone — propagates back through a webhook, updates a confirmation rate on a live dashboard, and triggers an escalation if they need help: that closed loop is what separates Zindua from every existing alert broadcast tool in the region.

What we learned

  1. Normalising heterogeneous external APIs into a consistent internal schema is harder than it looks — and more important than almost anything else in a data pipeline. The moment you have clean, uniform data, every downstream layer becomes simple.

  2. Prompt engineering for structured multilingual output requires explicit length constraints, register instructions, and local vocabulary guidance. "Translate this" produces bureaucratic text. "Rewrite this as if speaking to a village elder, under 120 characters, ending with one physical action" produces something a person can act on.

  3. Building a two-way feedback loop requires treating the absence of a response as data. Focal points who don't reply are as important to track as those who do — silence in an emergency is itself a signal. Every data source in the humanitarian sector that matters is harder to access than it should be. The communities most at risk of disasters are also the ones least served by the infrastructure built to protect them.

What's next for Zindua

Official Google Cloud Translation API with fine-tuned support for Oromo and Somali ICPAC seasonal forecast integration — when their API becomes accessible, Zindua is architected to add it as a third source with no changes to downstream layers Alert effectiveness analytics — tracking which hazard types, languages, and message framings generate the highest confirmation rates, and feeding that back into prompt design

Built With

Share this project:

Updates