LOTIS — Emergency Response GIS System

I built the full system solo — every architectural decision, every database schema, every dashboard screen was mine. LOTIS is a web-based GIS platform with multi-role dashboards: MDRRMO officers can view population vulnerability maps, identify high-risk zones, and coordinate evacuation routes through a Leaflet.js map interface. The data model was one of the harder design calls. Government records are structured around households, not individuals — so the schema had to reflect that hierarchy: household → family → individual — while keeping queries fast enough for real field use. I integrated KoboToolbox for field data collection, weather APIs for real-time conditions, and SMS broadcasting for alerts. Role-based access was non-negotiable given the PII involved: each user role sees only exactly what it needs, nothing more. Account creation requires verification against PWD IDs and government-issued identification — because this data has real consequences if it gets to the wrong hands.

The data I received from the BSPO was a mess. Incomplete, inconsistent, outdated. Some barangay records were missing entirely; others had duplicates or incorrect entries. Cleaning and mapping that to a reliable schema took longer than building most of the features — and it was my first real encounter with what government data actually looks like outside a classroom. No tutorial prepares you for that. Everything else was new to me at the same time: GIS concepts from scratch, shapefiles, coordinate systems, converting to GeoJSON, Leaflet rendering, connecting multiple external APIs while keeping the codebase from collapsing under its own complexity. Working alone meant I developed tunnel vision more than once — convinced a feature mattered, building it, realising it didn't. What pulled me out of that was bringing the actual MDRRMO staff into the process early. Showing them working prototypes and adjusting based on real feedback kept the project anchored to what they actually needed, not what I assumed.

I'd spend more time upfront on stakeholder analysis and architecture planning. A lot of my early decisions were based on developer assumptions — what I thought users would want — and some of those cost time I could have used better. The gap between what a developer imagines and what a user actually needs is real, and I felt it. I'd also want to build this with at least one other developer. Working solo on a system this complex creates blind spots you stop noticing after a while. The discipline of explaining your decisions to a peer — of having someone push back — shapes better software. I'd also design the monolithic structure more deliberately from day one, with maintainability as a first-class concern rather than something I worked backwards into.