Crisis Management · Resilience

Smart Defense Radar

A lightweight situational-awareness dashboard built for the worst day — under 500KB, offline-first, designed to keep working when the server and the internet don't.

Architecture + buildLiveOffline-first
<500KBtotal size of the client-side dashboard
2Gnetworks it is designed to stay readable on
0single points of failure — survives both server and internet loss
0$infrastructure cost — Google Sheets as the real-time database

The problem

CONTEXT

Dashboards fail on the worst day

Crisis-management tools assume connectivity, servers and infrastructure will be available — exactly the things that fail first in a real crisis. A dashboard that goes dark when the network does is worse than no dashboard, because people trust it.

The constraint is the product

The design question wasn't "what features can we add" but "what must keep working when everything else stops." Resilience wasn't a non-functional requirement — it was the core product decision every other choice answered to.

What I built

BUILD

An offline-first client

The entire dashboard is client-side and under 500KB — small enough to load over 2G and to keep rendering with no backend round-trip. If connectivity dies mid-session, the last good state stays on screen.

No-code ingestion

Activepieces automations collect public reports and push them into the shared state — a data pipeline assembled from existing automation instead of custom server code that would need operating and monitoring.

Zero-cost real-time storage

Google Sheets acts as the real-time database: no server to run, nothing to bill, and an interface anyone on the team can read and repair directly. The "cheap" choice was also the resilient one.

How it behaves under failure

RESILIENCE

Interactive map, degraded gracefully

Reports appear on an interactive map as they arrive. On constrained networks the map stays usable — the client renders what it has, and catches up when the connection returns.

Failure was the test plan

Each design choice was weighed against a scenario: server down, internet down, both down. Features that couldn't survive a degraded environment were cut — not deferred, cut.

The decision

OUTCOME

Infrastructure limits as product requirements

The project's core lesson: constraints like "must survive 2G" and "no budget for servers" don't block a product — treated seriously, they become the specification. Every limit produced a design decision that a well-funded build would have missed.

Stack & links

TECH

Stack

Cloudflare WorkersActivepiecesGoogle SheetsOffline-firstInteractive maps

Links

← PreviousPrompt Packer Next →AdQuest