03 — Final Degree Project · TFG · 2024–2025
UnidosYa
Role
Solo Developer
Stack
Flutter · Firebase · Google Maps API
Platform
Android (iOS-ready)
Institution
UPV Valencia — Honors
2.17s
Avg. matching time
99.7%
System availability
87.3%
Task completion rate
1K+
Concurrent users
01 — Overview

Built for a real crisis.
Deployed in response
to the Valencia floods.

UnidosYa is an Android mobile application that coordinates affected individuals and volunteers during natural disasters. It was directly inspired by the 2024 Valencia DANA floods — the deadliest natural catastrophe in Spain since 1957 — which killed over 200 people across 75 municipalities.

More than 50,000 spontaneous volunteers mobilised, but their efforts were severely hampered by a complete lack of digital coordination tools. Coordinators were using phone calls and spreadsheets. UnidosYa was built to solve that.

The system enables real-time volunteer-to-task matching, geolocation-based mission assignment, and secure communication — all GDPR-compliant and with offline operability for disaster-affected environments.

⚠ The Real-World Context
The Valencia DANA floods of October 2024 exposed a critical gap in emergency response infrastructure. With 50,000+ volunteers and no coordination system, response efforts were chaotic. Matching a volunteer to a task took 5–8 minutes by phone. UnidosYa reduces that to 2.17 seconds — 99% faster. This wasn't a hypothetical problem. People died waiting for help that was nearby.
02 — Problem Solved
📞
Manual matching bottleneck
Coordinators relied on phone calls or spreadsheets — 5 to 8 minutes per volunteer assignment. With hundreds of requests per hour, this was untenable.
📍
No geolocation filtering
Volunteers were deployed without regard to proximity or physical capacity, wasting critical time and logistics while nearby help went unmatched.
🔄
Zero real-time sync
Duplicate efforts, resource misallocation, and zero visibility into mission status. Multiple teams arriving at the same location, others with no help at all.
📡
Connectivity dependency
Existing digital tools required stable internet. During floods, connectivity fails. Any app not built for offline use becomes useless exactly when it's needed most.
03 — Technology Stack
Flutter / Dart
Frontend Framework
Cross-platform mobile development targeting Android first, iOS-ready. Provider pattern for reactive state management decoupled from Firebase streams.
Firebase Firestore
Real-Time Database
NoSQL real-time database with denormalised data for read performance. Firestore listeners propagate all changes instantly across connected clients.
Firebase Auth
Authentication
Role-based access control for two distinct user profiles — Volunteers and Affected Individuals. Security rules enforced at database level, not client-side.
Firebase FCM
Push Notifications
Contextual push alerts for new missions, status changes, and communications. Instant delivery ensuring volunteers never miss a nearby opportunity.
Google Maps API
Geolocation & Mapping
Interactive maps with real-time volunteer and mission positions. Haversine algorithm for server-side geographic distance filtering before UI rendering.
Git / Agile
Dev Process
Iterative sprint-based development with version control. Repository pattern to abstract data access layers, enabling future backend migrations.
04 — Architecture Decisions
Serverless Backend
Firebase serverless architecture eliminates infrastructure management and scales automatically. The free tier validated the system for 1,000+ concurrent users — zero backend ops overhead.
Real-Time Listener Pattern
All data changes propagate instantly across connected clients via Firestore listeners. No polling, no stale data — critical in time-sensitive emergency scenarios.
Offline-First Design
Critical data cached locally using Firestore offline persistence. The app remains fully operational during connectivity loss — the exact scenario it was built for.
Haversine Geo-Filtering
Geographic distance calculations executed server-side before data reaches the UI. Volunteers browse and filter tasks within a configurable radius of up to 25 km.
Security-First Rules
GDPR-compliant data handling with granular Firestore security rules and role-based access. No unauthorised cross-user data access — verified in testing. Security enforced at the database level, not the client.
Repository Pattern
Data access layers abstracted from business logic. The architecture is designed to support a future backend migration (e.g., to Node.js/Supabase) without rewriting the entire codebase.
05 — App Screenshots
01 Onboarding / Login Screen
02 Volunteer Home / Mission List
03 Map View with Pins
04 Mission Detail Screen
05 Affected Individual Request Flow
06 Notifications / Completion
06 — Skills Demonstrated
Full-Stack Mobile Dev
End-to-end Flutter/Dart development with Firebase backend integration, state management, and auth flows — built solo.
Real-Time Systems
Firestore listener architecture for instant cross-client synchronisation. No polling. No stale UI. Designed for high-urgency contexts.
Geospatial Engineering
Google Maps API integration with Haversine-based server-side distance filtering, radius configuration, and live pin rendering.
Security Engineering
GDPR-compliant system with role-based Firestore security rules. All access control enforced at database level — not client-side.
System Design
Scalable NoSQL schema with denormalised data for read performance. Repository pattern ensures the architecture survives backend migrations.
Agile Delivery
Iterative sprint-based development, version control discipline, and a 98-page academic paper documenting every technical decision.
SDG 11 Sustainable Cities & Communities
SDG 13 Climate Action
SDG 17 Partnerships for the Goals
View on GitHub ← All Projects
Next: Friend.ship