CLIENT: Surmapar Flood Response Partnership🇧🇩Bangladesh

Rising Water - Flood Early Warning With a Human Confirming Every Alert

Village Flood Alert Console for a Bangladesh District Partnership

Designed and built a clickable flood early warning console for a district disaster management office and a local NGO in north-east Bangladesh: river and rain gauges propose an alert stage for each village, a duty officer confirms and sends it in Bengali by SMS, voice call, siren and loudspeaker, and every delivery and volunteer acknowledgement is tracked village by village.

Scope of Work
Product design, UI build and clickable demo
Industry
Climate & Nature / Flood Early Warning
IoT
Compliance & Certifications
Disaster Management Act 2012Standing Orders on DisasterBTRC bulk SMS rulesBangladesh personal data protection lawCAP 1.2Early Warnings for All

Most of our work is under NDA. Per agreement, we can share the work but not the company details - all names and identifying information shown here have been changed.

Impact

5 Screens
Clickable end to end

Situation board, map with a 72 h replay, alerts list, alert detail and the 4-step New alert flow. Each of the 14 demo alerts opens its own detail page with delivery by channel and a timeline.

2 People
Behind every evacuate order

No alert of any stage is sent without a duty officer confirming it. An evacuate order swaps Confirm and send for Request authorisation, so a second, authorising officer has to approve it.

70 / 67
Bengali SMS counter

Bengali goes out as Unicode, so one SMS holds 70 characters and 67 per part once split. The composer counts characters and parts against the 2-part policy and flags the voice recording when the text is edited.

28 Villages
Realistic demo data

28 villages with Bengali names in 18 unions across 3 upazilas, 8 river and 3 rain gauges with 24 h readings, 14 shelters, 5 channels, 6 proposals and 14 alerts with delivery counts.

The Problem

The partnership relayed flood warnings by phone tree: the duty officer read the national forecast bulletin and rang union chairmen, who rang ward members, who walked to the villages. Nobody knew which villages had actually been told, warnings were text-only where many older people and women cannot read them, congested networks dropped calls on the worst nights, and the last after-action report took five weeks to assemble from notebooks and WhatsApp screenshots.

Our Solution

Rising Water watches river and rain gauges and the FFWC and BMD forecasts, proposes a watch, warning or evacuate stage for each village when a threshold is crossed, and lets a duty officer confirm and send it in Bengali by SMS, voice call, community siren and loudspeaker. Delivery, volunteer acknowledgements and door-to-door checks are tracked per village, so the officer sees who has heard and who has gone quiet.

The Challenge: Warnings That Reach Every Village in Time

Flash floods in the Sylhet region can rise within hours when heavy rain falls in the hills upstream. The partnership covers about 240 riverside villages in 18 unions, and a warning only counts if it reaches the people in them, including those who cannot read a text.

A Machine Must Not Order an Evacuation

Gauges and forecasts can suggest a stage, but the decision belongs to people working inside the disaster management committees set by the Disaster Management Act and the Standing Orders on Disaster. Every alert needs a duty officer, and evacuate needs a second, authorising officer.

Official Forecasts Are Not Ours to Issue

FFWC publishes river forecasts against a danger level for each station and BMD publishes rainfall forecasts. The product has to show and credit them as sources, and never present its own threshold alerts as an official national forecast.

Many Channels, Weak Networks

Bulk SMS goes through BTRC-registered aggregators or operators, Bengali texts are short Unicode messages, many people need a voice call, siren or loudspeaker instead, and on flood nights delivery receipts slow down or stop. The officer needs to know which channel is failing and where.

Vulnerable Households, Personal Data

Volunteers visit older people, people with disabilities, pregnant women and young children in person. That means holding phone numbers and household needs, collecting only what a warning needs, with consent recorded and nothing personal on the public page.

Our Approach: From Warning Practice to a Clickable Console

01

Spec and Rules Research

Mapped 9 roles from duty officer and authorising officer to village volunteers and the public, 40 screens across the operations console, an offline-first volunteer app and public status pages, and the data model for gauges, readings, forecast bulletins, versioned thresholds, proposals, alerts, dispatches, deliveries, households, shelters and audit. Wrote down the rules the design follows: the Disaster Management Act and Standing Orders on Disaster, FFWC and BMD as credited sources, BTRC bulk messaging, personal data protection, the four pillars of Early Warnings for All and CAP export.

02

Clickable Demo on a Production UI Kit

Built 5 key screens on a production dashboard kit: the situation board with proposed alerts, rivers against danger level and FFWC 24/48/72 h forecasts, villages needing follow-up and channel health, a map with layer toggles, a 72 h replay and village selection, the alerts list with review and dismiss, alert detail with the frozen trigger snapshot, delivery by channel and real CAP 1.2 XML and CSV downloads, and the 4-step New alert composer with pre-send checks. All actions run on local state.

03

What a Production Build Adds

Gauge telemetry over GSM with satellite backup, the FFWC feed by data sharing agreement and the BMD forecast, a BTRC-registered SMS aggregator and operator routes, voice broadcast, GSM siren controllers with a VHF fallback, MapLibre maps and a CAP feed. Staff auth by role and duty roster, an append-only audit log, and the remaining screens: gauges, villages, households, volunteers, shelters, evacuation, after-action review, settings, the volunteer app and the public status pages.

Why It Works: The System Proposes, People Decide

Proposals Wait for a Person

Each proposal card states the stage, the villages and the exact reason, such as a gauge 0.18 m below its danger level and rising 9 cm/hour, and turns red after 10 minutes waiting. Dismissing one needs a reason, and the board reads "No alert leaves without a person confirming it".

The Officer's View Is Frozen With the Alert

Alert detail keeps the trigger as the officer saw it at confirmation: the gauge reading, the FFWC danger level, the rule version and a 24 h chart with watch, warning and danger lines, next to who confirmed and who authorised.

Checks Before Sending

The composer lists what could stop a warning landing: a village with no volunteer, a faulty siren, a silent gauge, a degraded SMS route or a damaged shelter, alongside the gauges, previous alerts and shelters near the selected villages.

Every Village Accounted For

Delivery is shown per channel and per village: SMS, voice, siren, volunteer acknowledgement and door-to-door progress, with masked phone numbers in the delivery log. Villages with no acknowledgement after 30 minutes move onto the follow-up list.

Related case studies

View all: Climate & nature
Logo
Oceanlab

Enterprise Software Engineering - Human + AI

Languages

Locations

Global Headquarters

21 Merchant Road, 3rd Floor, Singapore 058267

Main corporate office and leadership operations

North America Office

548 Market Street, PMB 12345, San Francisco, CA 94104

Client operations and business development

India Office

402 Shivalik Shilp II, SG Highway, Ahmedabad 380015

Engineering and delivery center

© 2026 - Copyright. All Rights reserved Oceanlab