DRRM-ERS — PDRRMO Disaster Reporting System

I built DRRM-ERS as an intern at PDRRMO Iloilo — sole developer, 486 hours, from January to April 2026. Every architectural decision was mine to make and defend. The system is a full-stack Next.js application with tRPC for a type-safe API layer, Prisma ORM against a Supabase PostgreSQL database, and Dexie.js managing an offline-first submission queue via IndexedDB. The NDRRMC reporting template has 21 structured annexes — affected population, casualties, damaged infrastructure, evacuation data — and I had to model all of them correctly in a 30+ table schema. Two design decisions shaped everything. First: versioning instead of editing. When a municipality updates a SitRep, the system creates a new version rather than overwriting the previous one. Disaster situations evolve, and the full history of how they evolved matters — for post-disaster review, for inter-agency coordination, for government accountability. Second: security enforced at the API layer. Hiding a button in the UI is not security. Every tRPC procedure checks authorisation before any business logic runs. MDRRMO accounts can touch only their own municipality's data. Full stop.

The most technically demanding phase was the offline layer — and I underestimated it badly going in. Offline-first systems have failure modes that connected systems don't. An abrupt disconnection mid-submission, a device restart between capturing and syncing, a network that recovers and drops again in rapid succession — all of these had to be handled correctly, because field environments during disasters are exactly this unpredictable. I built the offline submission queue with Dexie.js, then stress-tested it under rapid connect/disconnect cycles. That testing revealed a subtle data duplication issue that only appeared under aggressive reconnection conditions — realistic in the field, invisible in normal development testing. I added a sync debounce layer and a lock mechanism to prevent simultaneous sync processes before it could reach production. The deeper lesson wasn't technical. PDRRMO staff during an active typhoon aren't sitting comfortably at desks. They're on calls, dealing with uncertain incoming data, working under emotional weight and time pressure. Every UI decision — error messages, loading states, how forms were structured — had to account for that. The goal was never to make something that impressed developers. It was to make something a stressed MDRRMO encoder could use without having to think about the software.

The offline layer I shipped uses browser IndexedDB through Dexie.js. It works, but it has limits: it's tied to the browser, it doesn't survive reinstalls cleanly, and it depends on browser APIs that can behave differently across devices. I'd rebuild it to be more robust — a fully redundant offline layer that doesn't depend on browser storage at all, one that can sync across reinstalls and survive device restarts. The goal I have in my head is a system that works whether the network is perfect, intermittent, or completely absent, with no asterisks on that last condition.