Last Saturday I watched fifty people spend a day building emergency management tools for Wellington City Council at the Wellington Claude Impact Lab. Ten teams, five problem statements from the Council's own emergency management team, one day. The entry that won was not the most polished build in the room. It won because the team understood something about the problem that no amount of polish can substitute for: an emergency tool that fails when the internet does is not an emergency tool.
What the winning team built
Their problem was helping emergency staff sort and prioritise incoming information. Their pipeline took a public report, asked one clarifying question, checked the report against live official data sources for the same location, triaged its severity in that context, and put one prioritised, location-grouped item in front of staff.
The detail that mattered: the triage ran on two small fine-tuned models hosted locally. No third-party LLM API. No per-token cost. No external vendor in the critical path. When the judges asked why, the answer was the whole insight: this tool is for the day the city is cut off. Design for that day, or you have designed for a different product.
The disaster takes your dependencies with it
Wellington sits on a fault line. The region declared a state of emergency during the April floods this year. Nobody building software here needs the failure scenario explained to them, and yet almost all of us default to architectures that assume the happy path: cloud APIs reachable, DNS resolving, credit cards working, rate limits generous.
For most software, that default is right. Cloud dependencies buy you capability you could never self-host, and I spend my working life arguing for exactly that trade. But resilience software inverts the logic. The event you are building for is precisely the event that degrades your dependencies: connectivity first, then power, then the supply chains behind every service you call. A dependency audit for an emergency tool is not "what happens if this API is down for an hour". It is "what does this tool do during the two weeks the city is on generator power and the cables are broken".
A test you can apply
My recommendation for anyone building or buying civic resilience software is a single exercise: list every network call your system makes, then rerun your core user journey with all of them failing. What still works is your actual product. Everything else is a nice-to-have.
Three design consequences tend to fall out of that exercise:
- Local inference is now a real option. Small fine-tuned models running on hardware you control were, until recently, a poor substitute for frontier APIs. For narrow, well-scoped tasks like classification and triage, they are now good enough, and "runs without the internet" beats "slightly better answers" in this domain every time.
- Degrade in stages, not to zero. The winning design used live official data sources when reachable and still functioned without them. Connectivity should improve the tool, not constitute it.
- Cost structure is a resilience property. A per-token price on an emergency tool means your worst day is also your most expensive one, at exactly the moment procurement is not answering the phone. Fixed-cost local capacity has no surge bill.
Usefulness beats polish
We published the judging criteria from the stage before the teams started, under one heading: usefulness beats polish. Usefulness to the Council carried the most points, working with real data came second, and a working demo came third. I had wondered whether stating it that bluntly would flatten the demos. The opposite happened: teams spent their day on the problem instead of the pitch, and the demos were better for it.
The offline-first insight is what that rubric looks like when a team takes it seriously. Polish is what a product looks like on a good day. Usefulness, for emergency software, is what it does on the worst one. If you are commissioning, judging, or building tools that public institutions will lean on when things break, put the internet connection on the list of things that break, and score accordingly.