Full-Stack Crisis Communication for Public Authorities

Problem & constraints

I work at a crisis-communication company whose software serves public authorities. One gap stood out: when something happened, local authorities still sent situation reports to their district control room on paper and in Word files. The reports needed a shared structure, a visible status and a history.

The reporting module has been through a field test with the municipalities of one district and is not yet in production, so its outcomes below are from that field test, not from live operations.

My role covers the whole stack, and more than one product: web, backend, Android tablets, a web app for residents and public displays. I run technical decisions, and other developers work from my plans and reviews.

Architecture

The reporting module is an Angular and PrimeNG client over a Java and Play Framework backend with MySQL. On one side sits a multi-page reporting form with validation, plausibility warnings, draft autosave and rule-based priority suggestions. On the other sits the control room’s dashboard, with combinable filters, report processing, change history and CSV export, plus a read-only review mode. Accounts, role-based navigation and permissions cover each authority.

The public-information display system has an Angular operator interface, a Java and Play middleware and a Python rendering layer that draws the notice, including its maps, for an e-paper panel. Rollout is driven by configuration: a new location needs a site file and a one-off map fetch, with no source change.

The decisions behind all of these are logged below, each with the alternative it beat.

The field tablets

The tablet app is for vehicle crews working through a blackout, when public networks may be gone. The tablet joins a Wi-Fi access point in a kit carried with the vehicle, and a private radio link carries the traffic to the control room. A crew reports that it is ready, receives an assignment with its stops, chooses the next stop, sees the route on an offline map, and reports position, status and results back. Text chat and emergency reports use the same link.

The app keeps working without a connection. Map and routing run on the device, and apart from position updates, outgoing messages wait in SQLite and are sent again until they are acknowledged.

The app is older than my time on it. My part was to carry it from Android 6 to 13 with a full UI overhaul, where I made the decisions on every part, to build a redesign line with sidebar navigation, turn-by-turn guidance, an updated map and quoted replies in chat, and to build backup and restore, so a technician can fully re-provision a device from one file. I sometimes take feedback from customers directly.

A web app for residents

When the power and the phone network are out, residents can join a local Wi-Fi network from a station on site and open a web app in their browser. I built it and made the decisions on every part of it.

They can file a guided emergency report: the address, a few short questions from a decision tree, a review, then send, and the report reaches the emergency services. They can describe how things stand where they are and then see help locations on a map, or offer help themselves. The app is multilingual.

It is a web app whose pages call a Java and Play backend. If the backend cannot be reached, the browser keeps the report and tries again.

Working across two clients

The Angular client exists in two forms: the current client, and a version migrated to a newer Angular with a full redesign. I keep the two in step, so the same feature behaves identically in both. The tablet app also has its redesign line alongside the current design on Android 13.

Outcomes

Authorities can now submit structured reports that the control room sees live, processes, and can trace back through their history, instead of handling paper and Word files. The module went through its field test, with accounts, permissions and a realistic exercise scenario prepared for each participating municipality.

The display system was tested on real hardware. Because of the delivery layer, swapping its whole hardware stack did not touch the application. The tablet app has been tested on hardware, and its backup and restore has been released to field tablets, after scripted end-to-end checks that included fault injection.

The residents’ web app is built, and its reports have been shown to reach the emergency services. I have no figures from real use, so I claim none.

Lessons

Three lessons stayed with me. First, test concurrency on the real database: running the scenarios on MySQL told me more than reasoning about the locks had. Second, an abstraction proves itself when the thing behind it actually changes; the hardware swap was the test of the delivery layer, and it held. Third, in public communication, wording is part of the system: status has to be carried by text and symbol rather than colour alone, and a technical delivery confirmation must never be presented as proof that someone has checked the display.