In March we wrote about why we started MeteoTrail. In June, about how we built it. This post is different — less about architecture, more about something that took us a full season to actually understand. Val d'Aran by UTMB was our first client where the software we build doesn't just inform people, it sits underneath decisions that can't be taken back: whether a stage starts on time, whether a section gets rerouted, whether runners get pulled off a ridge before a storm arrives. Getting through an entire race season with that kind of client changed how we think about engineering, in ways that have nothing to do with frameworks or infrastructure.
1. When software sits underneath a decision that can't be undone
Most software failures are recoverable. A bug ships, someone complains, you patch it, you learn, you move on. That's the rhythm most of us build our habits around, and it's a healthy one — until the thing you're building stops being a tool people consult and starts being the thing underneath a decision made in real time, on exposed terrain, with no way to walk it back. The Val d'Aran by UTMB race director once put it to us simply: he can't control the weather, but he has to make decisions based on it, and our job wasn't to hand him a nice dashboard — it was to be trustworthy enough to sit underneath that decision. Once that sinks in, the question you ask about every feature changes. It stops being "does this work" and becomes "what happens if this is wrong, right now, with someone on a ridge above the treeline."
2. False alarms vs. missed warnings
Most product thinking optimizes against noise. You tune alerts to be quiet, because users tune out anything that cries wolf, and every false positive erodes trust in the next real one. We had to unlearn a chunk of that instinct. In a live ultra-trail race, missing a real lightning risk is not a symmetric mistake against sending one alert too many — it's categorically worse. So we shifted how we think about thresholds: when the checkpoint-level conditions, the 48h and 7-day forecasts, or the real-time lightning data sit anywhere near a risk boundary, we'd rather surface it and let the race director and the hired meteorologist weigh it with full context than quietly suppress it to keep the interface clean. Occasional over-caution is a cost we're willing to pay. A missed warning during an event with runners already on the course is not a cost — it's the exact failure the whole system exists to prevent.
3. You can't fully test for race day
You can load-test the infrastructure. You can rehearse checkpoint flows, run tabletop exercises with the organizers before the event, and walk through what happens when the official agency alerts across different countries disagree with each other, or when a data source goes stale exactly when someone needs it most. What you can't do is recreate a real storm rolling over a mountain pass with hundreds of runners already committed to a stretch of trail and a meteorologist typing a manual report under real time pressure. We stopped chasing an illusion of complete pre-race certainty and started building for resilience instead: layered data sources so no single feed is a single point of failure, a manual override that always lets the human meteorologist publish a report that overrides anything automated, and being honest with the race team, before the gun goes off, about exactly what we'd tested and what would genuinely be happening for the first time.
4. What changed in how we build
Concretely, this is what a season like this left us with:
- We handle disagreeing or stale data explicitly, instead of silently picking a source and hoping it's the right one.
- During an actual event weekend, someone from the studio is reachable and watching dashboards in real time — not reviewing logs the next morning.
- Anything alert-related defaults conservative first, and gets relaxed later, never the other way around.
- The backoffice for the hired meteorologist is never a nice-to-have; it's the manual override that always outranks anything automated.
- We debrief after every event the way you'd debrief after an incident anywhere else, whether or not anything went wrong.
None of this shows up in a changelog. It's not a feature we can screenshot. But it's the thing that actually changed after this first full season with Val d'Aran by UTMB, and it's now how we default to thinking about any tool of ours that ends up underneath someone's real decision. The responsibility is heavier than we expected going in. It also made us better at this.