Floodwatch, and the Parts of Smart-City Infrastructure That Aren't Code

For my final year at UVA, I worked on a project called Floodwatch — a flood detection and warning system for Vietnam, built as the first real use case for a larger idea: the technical foundation a “smart city” would need. It had two parts. There was a mobile app where people could see current flood levels and get warned during an emergency, and there was the thing behind it that I spent most of my time on — a data pipeline that pulled information from a lot of different sources into one place.

The pipeline itself wasn’t complicated, and that turned out to be the point. A collaborator — at the start, a team at Ho Chi Minh University — would log into a shared cloud machine and drop data files into a folder. From there it ran on its own: the files were backed up to Amazon S3, a small Lambda function cleaned and reformatted them, the results went to Mapbox to be rendered as map layers, and the app pulled those layers so people saw flood data update through the day. Drop a file, and a while later it’s live on a phone in Vietnam.

The interesting problems weren’t inside that pipeline. They were in everything around it.

Floodwatch had four main groups of stakeholders, and they all needed something different from the same system. The US State Department was interested because student collaboration with a Vietnamese university was the kind of academic exchange they wanted to facilitate for US–Vietnam relations — and we wanted to support that while keeping the project itself apolitical. Our academic collaborators in Vietnam had data and wanted help making sense of it. Vietnamese citizens were the app’s actual users, both viewing flood data and, by being on the ground, validating it. And Vietnamese government and infrastructure officials — including the water companies that hold hydrological data — could supplement the app and use real-time citizen reports during an emergency. Designing one system that served all four without compromising any of them was the real problem, and most of it wasn’t technical.

Four issues came up again and again. The first was security: the data lived on S3 behind API keys we rotated every year, and we kept our URLs out of public repositories — basic stewardship, plus an obligation to disclose responsibly if anything ever leaked. The second was data ownership: when a citizen, a university, and a water company all touch the same dataset, who owns it? Our answer was to work toward data-sharing agreements and joint ownership, which we were still figuring out. The third was data collection and privacy: a geotagged flood photo taken from someone’s porch is, functionally, their home address, so the right default was to collect the minimum and anonymize it. The fourth was abuse: letting people upload images means someone can upload something harmful, so we planned to screen uploads with Amazon Rekognition — aware that a pretrained model carries its own biases, and that it works best paired with human reporting rather than trusted on its own.

The ambition was that Floodwatch would be a template — not one flood app, but a pattern other smart-city projects could reuse, with a modular pipeline, a configurable app, and a documented ethical framework. I don’t know yet whether anyone will use it that way.

What I’m taking from it is the part I didn’t expect going in. The hardest problem wasn’t the pipeline; it was getting institutions with no prior reason to trust each other to share data at all. Who controls the data, who controls the compute, and what has to be true for an institution to trust a system enough to actually use it — that was most of the work. I suspect it will be most of the work anywhere a system like this gets built.