Una app offline-first es aquella diseñada para funcionar sin conexión a internet como comportamiento por defecto, no como una degradación de emergencia. La diferencia con una app convencional es de raíz: en una app online, la fuente de verdad está en el servidor y el dispositivo es una ventana que se queda en blanco cuando falla la red; en una app offline-first, la fuente de verdad es la base de datos local del dispositivo, la interfaz responde siempre de forma instantánea contra esos datos, y un motor de sincronización se encarga de reconciliar los cambios con el backend cuando hay conexión disponible.
El caso de uso que hace imprescindible el offline-first es el de usuarios que trabajan en condiciones de red poco fiables: repartidores y operarios de almacén sin cobertura estable, técnicos de mantenimiento en instalaciones industriales, personal sanitario en zonas sin señal, explotaciones agrícolas remotas o puntos de venta en tiendas con wifi saturada. En todos estos escenarios, obligar al usuario a esperar a que responda un servidor —o peor, bloquearle el trabajo cuando no hay red— es un fallo de producto, no un inconveniente menor. El offline-first convierte la conectividad en un detalle de infraestructura invisible para quien usa la app.
La parte difícil del offline-first no es guardar datos en local —eso es sencillo— sino reconciliarlos sin perder información cuando vuelve la conexión. Si dos dispositivos han editado el mismo registro mientras estaban desconectados, ¿qué versión gana? La respuesta correcta depende del dominio. Para datos que se pueden fusionar automáticamente usamos CRDT (Conflict-free Replicated Data Types), estructuras de datos diseñadas matemáticamente para que todas las réplicas converjan al mismo estado sin coordinación central. Para registros donde el último cambio debe prevalecer, aplicamos last-write-wins con un reloj lógico que ordena los eventos de forma determinista incluso cuando los relojes de los dispositivos no están sincronizados. Y para datos críticos de negocio, implementamos merge por campos o resolución manual asistida, siempre con un registro de auditoría que permite reconstruir qué pasó en cada reconciliación.
Nuestro stack para offline-first combina Flutter en el cliente —con SQLite gestionado por Drift como base de datos local, SQLCipher para cifrado en reposo y una cola de operaciones persistente que reintenta cada cambio hasta confirmarlo— y Go sobre Cloud Run en el backend, con APIs idempotentes que garantizan que reenviar una operación nunca duplica el resultado. Generamos los identificadores en el cliente (UUID) para que el usuario pueda crear registros sin esperar al servidor, y sincronizamos de forma incremental por timestamps o vectores de versión en lugar de descargar todo el dataset en cada arranque. Cuando el proyecto integra hardware, esos mismos datos pueden llegar desde un dispositivo ESP32 por BLE y entrar en la misma cola de sincronización.
Dribba ha construido esta arquitectura en producción para apps de logística y para proyectos con hardware conectado, donde miles de operaciones diarias se registran sin cobertura y se sincronizan de forma fiable después. Si tu app actual pierde datos, duplica registros o se congela cuando la red falla, es exactamente el tipo de problema que resolvemos —tanto desde cero como rescatando una implementación offline que salió mal.
