First end-to-end ownership · small team lead · Tecon (Ekiba) · 2021–2022
GICA — wildfire management system for GEACAM
The system GEACAM's wildfire crews use to report their work from the field, even with no phone signal, while a web back office orchestrates shifts and campaigns and turns the day's work into management reports.
GEACAM is the public company in charge of preventing and fighting wildfires in Castilla-La Mancha. Out in the field, every crew is led by a capataz who has to report the day's work, and that information is what later feeds the running of the campaign.
The catch is that crews work deep in the countryside, often with no phone signal at all, and the reporting still has to happen every day. GICA is the system I built to make that work. It was also the first project I owned from end to end: requirements with the client, the architecture, the build, and a small team alongside me. What follows is a short overview, kept deliberately high-level.
How it works #s1
At the centre is a set of shared data — shifts, campaigns, crews — that has to be kept up to date from a web back office. That web is where GEACAM's staff orchestrate the shifts and campaigns that flow down to the field app, and where the day's work, once it comes back, is turned into the reports used to manage the working day.
On the other end is a mobile app, the only thing the capataces touch. Because crews can spend the whole day somewhere with no coverage, it's built to work fully offline: it captures the day's work on the device and syncs it back to the shared data once there's a connection again. The mobile app was delegated to a teammate; my scope was the full-stack platform behind it — the web back office and the data it all runs on.
From the daily report to the management reports #s2
Where the system earns its keep is the reports. From those daily field entries GEACAM has to produce the reports it runs the working day on: who worked in each unit, in which role, with which reliefs.
The hard part is shift changes. A crew isn't a fixed list: across the day and the month there are regulars, substitutions and people swapping shifts, and the report has to reflect who actually covered each position. Reconciling that by hand, unit by unit and day after day, was slow and easy to get wrong.
GICA streamlines it by automating it: from the field data it reconstructs who held each position, reliefs included, and generates the finished reports as downloadable files — one per unit, bundled together when several are requested. What used to be manual, error-prone work became a couple of clicks.
At real scale #s3
GICA was never a pilot. More than 2,200 users filed their work every single day, across Castilla-La Mancha — sustained, real-world use rather than a demo. That scale is also why automating the reports mattered so much: at that volume, reconciling shifts by hand simply doesn't hold up.
The technology, at a glance #s4
Under the hood it's a conventional three-tier setup, kept deliberately high-level here: the two clients — the field mobile app and the Angular management web — talk over HTTP to a Node.js and Express API written in TypeScript, which sits in front of a relational MySQL database.
What I took away #s5
GICA was where I first carried a product on my own shoulders: talking to the client, deciding the architecture, writing the code, and leading a small team. The freedom to move fast and own the outcome is still one of the things I've enjoyed most in my career.
It also grew well beyond its first scope, which taught me early how much a clean architecture pays off the moment a system has to grow into something its first spec never mentioned.