En marzo escribimos sobre por qué empezamos MeteoTrail. En junio, sobre cómo lo construimos. Este post es distinto: habla menos de arquitectura y más de algo que nos costó una temporada entera entender de verdad. Val d'Aran by UTMB fue nuestro primer cliente en el que el software que hacemos no solo informa a la gente, sino que sostiene decisiones que no se pueden deshacer: si una etapa arranca a su hora, si se desvía un tramo, si se retira a corredores de una cresta antes de que llegue una tormenta. Pasar una temporada de carrera entera con un cliente así nos cambió la forma de pensar la ingeniería, y no tiene nada que ver con frameworks ni con infraestructura.
1. Cuando el software sostiene una decisión que no se puede deshacer
La mayoría de fallos de software se pueden arreglar. Se publica un bug, alguien se queja, lo parcheas, aprendes y sigues. Es el ritmo con el que construimos casi todos nuestros hábitos, y es sano, hasta que lo que construyes deja de ser una herramienta que la gente consulta y pasa a ser lo que hay debajo de una decisión tomada en tiempo real, en terreno expuesto, sin forma de dar marcha atrás. El director de carrera de Val d'Aran by UTMB nos lo dijo una vez de forma sencilla: él no puede controlar el tiempo, pero tiene que tomar decisiones a partir de él, y nuestro trabajo no era darle un dashboard bonito, sino ser lo bastante fiables como para sostener esa decisión. Cuando eso cala de verdad, la pregunta que te haces sobre cada funcionalidad cambia. Deja de ser "¿esto funciona?" y pasa a ser "¿qué pasa si esto falla, ahora mismo, con alguien en una cresta por encima del bosque?".
2. Falsas alarmas frente a avisos que faltan
La mayoría del pensamiento de producto optimiza contra el ruido. Ajustas las alertas para que sean discretas, porque los usuarios dejan de hacer caso a lo que grita lobo demasiadas veces, y cada falso positivo erosiona la confianza en el siguiente aviso real. Aquí tuvimos que desaprender buena parte de ese instinto. En una carrera de ultra trail en directo, no detectar un riesgo real de rayos no es un error simétrico frente a mandar una alerta de más: es categóricamente peor. Así que cambiamos cómo pensamos los umbrales: cuando las condiciones de un checkpoint, las previsiones a 48 horas y 7 días, o los datos de rayos en tiempo real se acercan a un límite de riesgo, preferimos mostrarlo y que el director de carrera y el meteorólogo contratado lo valoren con todo el contexto, antes que suprimirlo en silencio para que la interfaz quede limpia. Pecar de cautelosos de vez en cuando es un coste que asumimos. Que falte un aviso durante un evento con corredores ya en el circuito no es un coste: es exactamente el fallo que todo el sistema existe para evitar.
3. No puedes probarlo del todo para el día de la carrera
Puedes hacer pruebas de carga en la infraestructura. Puedes ensayar los flujos de checkpoint, hacer simulacros de mesa con la organización antes del evento, y repasar qué pasa cuando las alertas oficiales de distintos países no coinciden entre sí, o cuando una fuente de datos se queda desactualizada justo cuando más falta hace. Lo que no puedes hacer es recrear una tormenta real cruzando un puerto de montaña con cientos de corredores ya metidos en un tramo del recorrido y un meteorólogo escribiendo un informe manual bajo presión de verdad. Dejamos de perseguir la ilusión de una certeza total antes de la carrera y empezamos a construir para la resiliencia: fuentes de datos por capas para que ninguna sea un punto único de fallo, un override manual que siempre permite al meteorólogo humano publicar un informe que prevalece sobre cualquier cosa automática, y ser honestos con el equipo de organización, antes del disparo de salida, sobre qué habíamos probado de verdad y qué iba a pasar por primera vez de verdad.
4. Qué cambió en cómo construimos
En concreto, esto es lo que nos dejó una temporada así:
- Tratamos explícitamente los datos que no coinciden o se quedan desactualizados, en vez de elegir una fuente en silencio y confiar en que sea la correcta.
- Durante el fin de semana real del evento, alguien del estudio está localizable y mirando los paneles en tiempo real, no revisando logs a la mañana siguiente.
- Todo lo relacionado con alertas parte de un valor conservador por defecto y se relaja después, nunca al revés.
- El backoffice del meteorólogo contratado nunca es un extra: es el override manual que siempre está por encima de lo automático.
- Hacemos un debrief después de cada evento como se haría tras un incidente en cualquier otro sitio, haya pasado algo o no.
Nada de esto aparece en un changelog. No es una funcionalidad de la que puedas hacer una captura de pantalla. Pero es lo que realmente cambió tras esta primera temporada completa con Val d'Aran by UTMB, y es como pensamos por defecto en cualquier herramienta nuestra que acabe debajo de la decisión real de alguien. La responsabilidad pesa más de lo que esperábamos al principio. También nos hizo mejores en esto.