Tayari

Inspiration

Early warning systems across the Horn of Africa have gotten genuinely good at predicting drought risk, rainfall anomalies, seasonal forecasts. But prediction is no longer the problem anymore. The real gap is what happens after a warning is issued: does it reach the people who need to act on it? Does it tell them anything specific to do? And once they act, does anyone actually know?

We kept coming back to one uncomfortable truth: a risk score means nothing to a pastoralist household with no internet access and no idea what "60% probability of below-normal rainfall" is supposed to mean for their next move. We wanted to build the missing link between 'knowing' a drought is coming and 'doing' something about it — one that works on the same basic phones most of these communities already carry.

What it does

Tayari is a drought preparedness tracker that closes the loop between early warning and early action.

• Community reporting via USSD **- no smartphone, no internet, no data plan required. A community representative dials a code on any basic phone and answers six short questions covering the real drivers of drought vulnerability: water access, pasture availability, livestock body condition, food stock, income source, and awareness of the nearest relief point. -Government Respondence*- These reports filled in by the community representatives are able to inform the government on the gaps and it is now their responsibility to fill in these gaps. This is done in a fast and economic way. -* AI-generated, plain-language guidance** -instead of a raw score, each report is translated instantly into a specific, actionable instruction via a generative AI model, tailored to exactly which needs are unmet.
• *Weighted gap-severity scoring *- not every missing item is equally urgent. Water and food security are weighted highest, since they threaten survival directly, while relief awareness is weighted lower. This produces a genuine severity index and a Low/Moderate/High/Critical classification, rather than a flat percentage that treats every gap as equal.
• Responder dashboard ** - county and NGO responders see wards ranked by severity, not buried in raw data, so the most urgent gaps surface first. - Accountability loop **- responder actions are logged with a timestamp, and the community can confirm whether the action actually happened, closing the loop from warning to verified action.

How we built it

Backend: Python (Flask) handling USSD session logic, request routing, and business logic.

• Database: PostgreSQL, storing wards, reports, and responder actions in a normalized schema.
• Telephony layer: Africa's Talking USSD API, tunneled during development with ngrok.
• AI layer: Google Gemini (gemini-2.5-flash) for generating context-specific, plain-language action guidance from structured gap data.
• Frontend: Server-rendered HTML/CSS dashboard and homepage, no external frontend framework, kept intentionally lightweight so it's fast to load and easy to extend.

Challenges we ran into

-Infrastructure chaining: getting Flask, ngrok, and the Africa's Talking sandbox to talk to each other reliably was harder than any of the actual logic ; ngrok URLs regenerate on every restart, which silently broke the callback registration more than once.

• Environment setup on Windows: PowerShell execution policies blocking virtual environment activation, PATH issues with multiple tools, and two overlapping PostgreSQL installs all had to be debugged one at a time.
• Designing for zero connectivity: almost every early warning tool we looked at assumes a smartphone and data access. Committing to USSD/SMS-only meant constantly asking "would this actually work on a KES 1,500 phone with no data bundle?" and cutting features that didn't pass that test.
• Choosing meaningful indicators, not just easy ones: our first draft of the questionnaire was too generic. We rebuilt it around real drought-impact domains mirroring how agencies like Kenya's National Drought Management Authority actually monitor vulnerability rather than indicators that were simply convenient to code.

Accomplishments that we're proud of

-A fully working, end-to-end system: a real USSD session writes real data to a real database and returns AI-generated guidance, live.

• A genuinely weighted, defensible severity scoring model instead of a naive "count the noes" approach.
• Built entirely for zero-connectivity access ;the design decision we're most proud of, since it's the one most similar projects skip.

What we learned

-How USSD session state actually works in production (the text parameter's *-delimited accumulation model)

• How to design a minimal viable schema that still supports real analytical scoring on top of it
• That the hardest part of "AI for good" projects usually isn't the AI — it's the unglamorous infrastructure plumbing that has to work perfectly for the AI to ever get called at all

What's next for Tayari

• Multiple community representatives per ward with a reconciliation and reliability-scoring model, so no single report can silently skew the picture
• Live integration with ICPAC's drought risk feeds (NDVI, rainfall anomaly) to automatically stage wards into Watch/Alert/Emergency
• A geospatial map view of ward-level severity for responders
• SMS fallback and IVR/voice support for lower-literacy users
• Evidence-based action confirmation (photo or reference upload) instead of a simple status toggle

Built With

• africa's-talking
• flask
• gemini
• generative
• html
• python
• ussd