Village-Level Flood Warning Web App in Urdu and Sindhi That Works Offline

The problem: knowing a flood is coming is not the same as knowing where to go

The 2022 floods in Pakistan showed how fast water can cut off whole districts in Sindh, Balochistan and southern Punjab. Warnings did come, from the national and provincial disaster authorities and through the news. What many families lacked was local detail: is my village in the affected area, which school or embankment is the evacuation point, which road is still open, which number do I call?

That local knowledge usually sits with district officers, local NGOs and volunteers. They share it through WhatsApp forwards and loudspeaker announcements, which do not reach everyone and cannot be checked later.

What already exists and the gap

• The PAK NDMA Disaster Alert app from the National Disaster Management Authority shares official alerts, with audio in Urdu and English and an archive of past alerts. It is built for national and provincial warnings and requires installing an app.
• Google Flood Hub publishes free short-term river flood forecasts for more than 80 countries, based on research from Google. It shows where rivers may flood, not where a particular family should go.
• WhatsApp groups run by NGOs and community leaders are fast but unstructured, and messages get lost among forwards.

The gap is a simple tool for the last step: local officers and NGOs publishing village-level warnings with evacuation points, in local languages, that people can receive without installing an app and can still read when the network fails.

Inspiration

Nearing and colleagues at Google ("Global prediction of extreme floods in ungauged watersheds", Nature, 2024) showed that machine learning can forecast floods several days ahead even where rivers have no gauges, and their forecasts power Google Flood Hub. Better forecasts only help if the warning reaches people in a form they can act on. Your project focuses on that delivery problem: turning a forecast or an official alert into a local, actionable message.

What you build

• District officers and NGO staff log in, select affected union councils on a map, choose a template, fill in details and publish.
• Residents open a short link once, choose their village, allow notifications, and get warnings in their language. The map of evacuation points stays on their phone.
• Coordinators see who was notified and which areas have few subscribers, so they can focus outreach there.

The technically interesting part

Even as a beginner project, there are real engineering problems to solve:

• Offline first. Use a service worker to cache the app shell, the latest warnings and map tiles for the chosen area. Test what happens when the phone is offline for two days.
• Tiny pages. Many people will open the link on a cheap phone with a weak signal. Budget every kilobyte, avoid heavy frameworks on the first page, and measure load time on a throttled connection.
• Location without tracking. Let people choose their village from a list instead of sharing GPS, and match it to warning areas with point-in-polygon checks on the server.
• Web push. Implement push subscriptions, handle expired subscriptions and record delivery.
• Right-to-left text. Urdu and Sindhi need proper fonts, line height and layout. Check them with native readers.

How to evaluate it

• Load performance: page weight and time to first useful content on a throttled 3G profile and a low-end phone.
• Offline behaviour: a checklist of tasks (read the last warning, find the nearest evacuation point) done with the network switched off.
• Delivery: time from publishing a warning to it appearing on test phones, across Android browsers.
• Usability: test with five to ten people from the target area or similar, in their language, and record what they misunderstood.

Suggested plan

• Weeks 1 to 2: talk to an NGO or a district disaster office, collect evacuation points for one district.
• Weeks 3 to 6: admin screen, warning areas and the resident page in three languages.
• Weeks 7 to 9: service worker, offline map and web push.
• Weeks 10 to 12: performance budget, delivery log and testing on low-end phones.
• Weeks 13 to 15: user testing, write-up and demo.

Path to a product

Local NGOs, district authorities and humanitarian groups need cheap, reliable ways to reach people, and many run similar programmes every monsoon. An open source tool they can host, with paid setup and SMS integration, is a realistic path. The project also shows employers that you can build for real constraints, which is rarer than another dashboard.

Scope warning

Do not try to predict floods yourself, and do not present your app as an official source. Warnings must come from authorised people, and the app should say who published each one. Start with one district and one partner, and get the offline experience right before adding more features.

Learn what you need on Sefism

• Frontend development roadmap: service workers, performance and progressive web apps.
• Frontend development cheat sheet: quick reference for the browser APIs you will use.
• Full stack development roadmap: the admin side, database and push service.
• PostgreSQL Documentation: storing areas and points, with PostGIS for the spatial queries.
• web.dev: offline patterns and performance budgets.
• Learn Accessibility: readable, usable pages for everyone.

Get help with this idea

The risk is a polished app with no real data or partner behind it. Tauseef can help you find the right first district, scope the offline features and plan user testing with people who would actually use it. If you are new here, create a free account first.

• Discuss this idea with a mentor
• Send a query to Tauseef
• Book a 1:1 session