NaturPark es uno de los productos que construimos en Maladeta Studio, junto a Lueira y MeteoTrail, y está en la intersección de dos áreas que nos interesan: la movilidad en espacios naturales y la gestión de residuos. El eslogan que acabamos usando lo dice sin rodeos: gestiona los espacios naturales de una forma innovadora y segura. Pero lo interesante de construir NaturPark no fue el eslogan, sino darnos cuenta pronto de que "un espacio natural" no es una sola cosa, y un software que finge lo contrario se rompe en cuanto llega el segundo cliente.
1. Un espacio, un reglamento — hasta que deja de serlo
La primera versión de la idea en mi cabeza era simple: construir una plataforma para gestionar espacios naturales, lanzarla, iterar. Bastó una conversación real con un gestor de parque para ver el problema. Un humedal costero se preocupa por ventanas de acceso según la marea, restricciones en época de nidificación y tráfico de embarcaciones. Una reserva alpina se preocupa por el estado de las sendas, el riesgo de aludes y cierres estacionales que no tienen nada que ver con mareas ni nidos. Ambos necesitan gestionar visitantes. Ninguno necesita las reglas del otro.
Es una trampa habitual en el software vertical: construyes para el primer cliente, generalizas un poco para el segundo, y al tercero estás manteniendo un montón de condicionales y feature flags ocultos que ya nadie entiende del todo. No queríamos llegar ahí por accidente, así que intentamos decidir a propósito, desde el principio, hasta dónde se flexionaría la plataforma — y dónde trazar una línea dura y decir "esto es el núcleo, lo tienen todos".
2. Diseñar para la modularidad
No todos los espacios son iguales y cada uno tiene sus propias necesidades — esa es toda la premisa, y por eso diseñamos la plataforma de forma modular y escalable en vez de como un paquete fijo de funciones. En la práctica eso significó separar un núcleo pequeño (perfil del espacio, cuentas de personal, datos básicos de visitantes) de un conjunto de módulos independientes que se pueden activar o desactivar por espacio: cosas como conteo de visitantes, reporte de incidencias, estado de senderos o rutas de recogida de residuos, según lo que ese espacio realmente gestione.
Los módulos anteriores son ilustrativos, no una lista exhaustiva de lo que se llegó a implementar — son el tipo de cosa que la arquitectura estaba pensada para soportar, dado el trabajo en movilidad y gestión de residuos que hacemos. Lo que importaba más que cualquier módulo concreto era el mecanismo: la configuración de un espacio decide qué muestra su dashboard, qué le pide la app móvil registrar al personal de campo, y qué modelo de datos se aprovisiona por debajo.
{
"space_id": "aiguestortes-01",
"name": "Aigüestortes",
"modules": {
"visitor_counting": true,
"incident_reporting": true,
"trail_status": true,
"waste_collection_routes": false,
"boat_traffic_control": false
}
}
El panel de administración es donde esta configuración se edita de verdad — quien da de alta un espacio nuevo elige los módulos que necesita, y todo lo demás, desde el dashboard del gestor hasta la lista de tareas que ve un guarda en el móvil, se adapta a esa elección en vez de mostrar menús muertos que nadie pidió.
3. Las tres caras del producto
NaturPark no es una interfaz, son tres, cada una pensada para un tipo de usuario y un contexto de uso distinto. El dashboard web es donde el equipo de gestión de un espacio tiene una visión general. El panel de administración es donde se configuran módulos y ajustes para un espacio concreto, normalmente por quien lo da de alta o por nosotros durante la puesta en marcha. Y luego está la app de campo.
La app de campo es la que tiene que funcionar sin ninguna de las comodidades de un trabajo de oficina: cobertura intermitente, guantes, reflejos del sol en la pantalla, alguien que quiere registrar una incidencia y volver a caminar por la senda, no rellenar un formulario. Diseñarla significó empujar constantemente la complejidad hacia el dashboard y el panel de administración, y mantener la cara de campo lo más cerca posible de "tocar dos cosas y seguir" que los módulos activados para ese espacio permitieran.
4. Qué haríamos diferente
La modularidad se vende fácil en una presentación y se vive más difícil en el código. Activar un módulo por espacio suena a un checkbox, pero toca permisos, modelado de datos y testing. Nos apoyamos en que los módulos son independientes más de lo que me gustaría admitir en la primera versión, y en general aguantó — pero ese "en general" hace bastante trabajo en la frase.
Si empezara NaturPark hoy, querría definir los límites de los módulos con el mismo rigor que le dimos al eslogan, desde el primer día, en vez de descubrir los límites reales conversación de cliente a conversación de cliente. NaturPark sigue funcionando sobre esa misma idea: espacios distintos, necesidades distintas, una sola plataforma debajo. De lo que no estoy tan seguro, años después, es de si "un módulo por función" era la granularidad correcta, o si la unidad real de variación era algo más grueso que dividimos en módulos sobre todo porque era más fácil construirlos de uno en uno.