Back to dashboard

Path to reality

What would have to be true for this to run for real — sources, partner, cost, and reach.

(a) From simulated to fully live, across all five basins

Rainfall is already live. Everything else that carries a Simulated badge in the app is listed below with the specific feed that would replace it.

InputTodayTo go live
Rainfall observationsOpen-Meteo public API, hourly, per basin centroid (live)A data-sharing agreement with the Kenya Meteorological Department for station-level gauge feeds, plus at least 2–3 gauges per basin rather than one centroid point.
River levelsNot modelled at allWater Resources Authority gauging-station telemetry, or ~4 low-cost ultrasonic river-level sensors per basin reporting over GSM.
Dam capacitySeeded dam_status rows, manually flipped (simulated)A reporting channel with KenGen for the Seven Forks cascade and WRA for the 192 catalogued high-risk dams — even a daily operator-entered percentage beats a static row.
Basin thresholdsEstimated 24h / 7d thresholds chosen for explainable behaviourCalibration against 10+ years of KMD/WRA archives per basin, reviewed by a hydrologist, with thresholds versioned so score history stays interpretable.
Citizen deliverySMS and voice rows queued to sms_alerts_log, rendered in-app (simulated)An Africa's Talking (or Safaricom) bulk-SMS and voice account with a registered sender ID, plus an opt-in register per ward.

(b) What a real pilot looks like

Not “the government.” One partner, one basin, one season. The two realistic first partners are the Tana River County Disaster Management Office (downstream of the Seven Forks cascade, so the dam-compounding factor is immediately meaningful) or a single Kenya Red Cross Society branch, which already runs ward-level volunteer networks and opt-in contact lists.

  1. Weeks 1–2: agree the basin, the two thresholds, and who is allowed to fire an alert. Load the county's own authority contacts into the authorities table.
  2. Weeks 3–4: shadow mode. Scores and alerts generate, but nothing is sent — the focal point compares each would-be alert against what they observed.
  3. Weeks 5–8: opt-in enrolment of ward volunteers and chiefs (target ~500 numbers), SMS only, English and Kiswahili.
  4. One long-rains season: alerts sent for real, with every fired alert reviewed after the fact for lead time and false alarms.
  5. Season review: publish hit rate, false-alarm rate, and median acknowledgment time before asking for a second basin.

Success criterion for the pilot is not “no floods.” It is: did the focal point trust the alert enough to act, and was it earlier than they would otherwise have moved?

(c) Rough operating cost, stated honestly

Bulk SMS
≈ KES 0.80 / message

10,000 recipients per basin alert ≈ KES 8,000 (~USD 60) per fired alert.

Voice / IVR call
≈ KES 3–5 / 30s call

Reserved for critical severity only; 2,000 calls ≈ KES 8,000 (~USD 60).

Hosting + database
≈ USD 25–50 / month

Managed Postgres and edge hosting at pilot scale; rainfall ingestion is one hourly job.

River-level sensors
≈ USD 250–600 each

One-off hardware, plus ~USD 2/month per SIM. Optional for a first pilot.

Human time
the real cost

One part-time county focal point to verify alerts and maintain the opt-in register.

A single-basin pilot with ~500 enrolled numbers and a handful of alerts per season lands in the region of USD 60–150 per month, dominated by hosting rather than messaging. Costs scale with recipients, not with basins — adding a sixth basin costs essentially nothing until you enrol its citizens. These are order-of-magnitude estimates from published operator rate cards, not quoted prices.

(d) Why the architecture travels

Basins are rows in a regions table, never a hardcoded list. A region carries its own name, centroid, 24h and 7d rainfall thresholds, and a has_dam_monitoring flag; scores, alerts, authorities, SMS logs and citizen reports all reference it by id. Adding a basin is an insert plus its threshold values and authority contacts — no code change, no deploy.

  • Rainfall comes from a global API keyed on latitude/longitude, so any coordinate on earth resolves.
  • Language is per-profile, so a new dictionary (Luganda, Amharic, Chichewa) extends citizen screens without touching logic.
  • Thresholds are per-region, which is what makes cross-border reuse defensible — the Zambezi is not the Nairobi River, and the rule never assumes it is.

The constraint on expansion is therefore not software. It is a local partner who can validate thresholds and own the send button.

9.2 — Regional expansion mockup

Wireframe mockup — not live data. The two highlighted basins do not exist in the database. This shows what the National Coordination View looks like once regions holds seven rows instead of five, including one outside Kenya. No component in this mockup is new: the same cards, markers and severity scale render whatever rows exist.

National & cross-border coordination view

3 / 7basins elevated
Wireframe
Nairobi River Basin
Mau Forest
Lake Victoria Basin
Aberdare Range
Tana Delta
Ewaso Ng'iro North
Lower Shabelle

Marker colour = severity, marker size = risk score. Basins outlined in the primary colour are the proposed additions.

Tana Delta
Kenya
Critical
88Monitored today
Lower Shabelle
Somalia
High
76Proposed basin
Nairobi River Basin
Kenya
High
71Monitored today
Ewaso Ng'iro North
Kenya
Moderate
51Proposed basin
Lake Victoria Basin
Kenya
Moderate
49Monitored today
Mau Forest
Kenya
Moderate
44Monitored today
Aberdare Range
Kenya
Low
22Monitored today
What it takes to make this real: two rows in regions (name, centroid, 24h/7d thresholds, has_dam_monitoring), their authority contacts, and a locally-validated threshold pair. Ewaso Ng’iro North extends coverage to Isiolo and Garissa; Lower Shabelle demonstrates a cross-border basin where the only Kenya-specific assumption to replace is the language set and the responding authority.