Offline-first no es una casilla: es el modelo de datos entero

En Jornia, antes de abrir F4 —cuenta de usuario y sincronización entre dispositivos— nos hicimos una pregunta incómoda: ¿cuánto se puede construir sin eso? La respuesta, después de agotar un backlog entero, fue: casi todo lo que importa.

Eso no fue casualidad. Fue un filtro que se aplicó a cada funcionalidad, una por una, antes de escribir una línea de código.

El filtro, no la lista

El backlog offline (docs/backlog-offline-preF4.md) no es una lista de "cosas guays que hacen los competidores". Es esa lista pasada por un filtro duro: factible sin cuenta ni red, o que degrade bien con caché. Todo lo demás se descarta o se aparca, por bueno que parezca en una demo.

Ese filtro es lo que separa "offline-first" de "también funciona sin conexión". La diferencia se nota en las decisiones concretas:

• Conversión de moneda por viaje se hace con una tasa cacheada o metida a mano, nunca con una llamada obligatoria en el momento de ver el gasto.
• El mapa del viaje se puede descargar por área con antelación (Mapbox TileStore + OfflineManager), verificado de verdad en modo avión — no "debería funcionar sin red", sino probado sin red.
• El escaneo de tarjeta de embarque parsea el estándar IATA BCBP enteramente en el dispositivo. Nada sale del móvil, y el código de la puerta se puede enseñar sin cobertura.

Ninguna de las tres es difícil de justificar por separado. Lo difícil es que las tres pasen el mismo filtro, y que ese filtro se aplique también a la que viene detrás, y a la siguiente. Ahí es donde offline-first deja de ser un adjetivo de marketing y se convierte en una restricción de arquitectura que toca cada feature.

Por qué esto es del modelo de datos, no de la conexión

La tentación fácil es tratar "offline" como un caso a mayores: la app funciona, y además hay una capa de caché para cuando no hay red. Ese enfoque funciona hasta que alguien pide algo que de verdad importa —reparto de gastos entre viajeros, backup completo, estadísticas agregadas de todos los viajes— y ahí se ve si el modelo aguanta.

En el análisis de cierre de esta etapa (docs/analisis-offline-v0.11.md) el criterio que se usa para medir "hecho de verdad" no es "funciona con wifi". Es más estricto: reparto de gastos con liquidación entre viajeros, estadísticas que se calculan de datos ya locales (kilómetros volados incluidos, con la fórmula de haversine sobre coordenadas que el mapa ya había geocodificado), backup export/import completo en JSON con adjuntos. Todo eso exige que el dato correcto ya esté en el dispositivo, no que se pueda pedir cuando toque.

Eso es lo que quiero decir con "modelo de datos entero": no es una capa de caché que se le añade a una app pensada para estar siempre conectada. Es diseñar la fuente de verdad para que viva en local desde el primer día, y tratar la red como algo opcional que enriquece, nunca como algo de lo que depende una función que el usuario ya considera básica.

La prueba de fuego: la app en modo avión, de verdad

La comparativa de mercado en ese mismo análisis es reveladora: frente a Tripsy, TripIt y Wanderlog, el offline de Jornia no es "parcial" ni "de pago" — es la única fila de la tabla marcada como total y gratis. Eso no sale de una promesa en la ficha de la store. Sale de que cada funcionalidad candidata se sometió al mismo filtro antes de entrar, y de que el mapa offline se verificó descargando un área real y comprobando el render en modo avión, no asumiendo que "debería funcionar".

Esa disciplina tiene un coste: cosas que parecen fáciles de justificar en abstracto —parsing de reservas por email, alertas de vuelo en tiempo real, sincronización entre dispositivos— se quedan fuera del backlog offline a propósito, porque no pasan el filtro. No es que no importen: es que pertenecen a otra fase (F4, F5, F6 en el roadmap), la que sí depende de red, y meterlas antes de tiempo habría diluido justo la propiedad que hace fuerte a las demás.

Lo que nos llevamos

Offline-first no se decide una vez. Se decide en cada feature, con el mismo filtro, hasta que se convierte en el reflejo por defecto del equipo en vez de una casilla que hay que recordar marcar.

"Funciona sin red" y "el dato correcto ya vive en el dispositivo" no son lo mismo. El primero es una propiedad de la conexión. El segundo es una propiedad del modelo de datos, y solo el segundo aguanta cuando la funcionalidad se pone seria (reparto de gastos, estadísticas, backup).

Verificar en modo avión no es opcional. Es la única forma de que "offline" deje de ser una promesa y pase a ser un hecho comprobado, con un área de mapa concreta descargada y renderizada sin datos, no una suposición razonable.

---

Si estás diseñando algo que tiene que funcionar sin conexión y quieres comparar el filtro que usasteis vosotros, escríbeme.