Aplicaciones local-first: cuando el trabajo no puede esperar a la conexión
Una inspección no debería detenerse por falta de cobertura. Así se diseñan aplicaciones que guardan primero en el dispositivo y sincronizan después, sin ocultar conflictos ni perder el control de los datos.
Un técnico entra en el sótano de un edificio, localiza una incidencia y abre su aplicación. Adjunta una fotografía, escribe una observación y pulsa guardar. La cobertura desaparece. La pantalla sigue esperando.
El problema parece de conectividad, pero también es de diseño: una tarea que podía resolverse en el dispositivo se ha hecho depender de un servidor remoto.
Local-first plantea que el trabajo continúe donde está la persona. Para aplicaciones de inspección, mantenimiento o visitas técnicas, esa decisión cambia la experiencia completa, desde el primer toque hasta la entrega del informe.
Qué significa diseñar una aplicación local-first
En una aplicación local-first, el dispositivo mantiene una copia de los datos con la que se puede trabajar. La sincronización permite compartir cambios cuando existe conexión. El planteamiento de Ink & Switch sobre software local-first vincula este funcionamiento con colaboración y control de la información por parte del usuario.
Su consecuencia práctica es que guardar una observación puede completarse localmente antes de enviarla. No basta con mostrar una pantalla almacenada: también deben funcionar las acciones esenciales.
El alcance se define por proyecto. Consultar expedientes descargados puede estar disponible; abrir un expediente nunca sincronizado, probablemente no.
La experiencia empieza antes de quedarse sin cobertura
Imaginemos una aplicación para revisar acabados de viviendas. Antes de salir, el técnico selecciona la promoción y descarga las unidades asignadas, planos, formularios y referencias necesarias. La aplicación confirma qué está preparado y cuánto espacio ocupa.
Durante la visita, cada incidencia recibe un identificador, una ubicación, fotografías y una descripción. El técnico puede corregir un dato, cerrar la aplicación y recuperar el trabajo al abrirla de nuevo.
La preparación merece su propia interfaz. Un botón de descarga sin indicación de avance deja dudas. Resulta más útil mostrar una lista de viviendas preparadas, recursos pendientes y fecha de actualización del plano. Así se evita confundir disponibilidad con vigencia: un plano guardado puede estar desactualizado.
También conviene permitir que la persona revise ese material antes de desplazarse. Descubrir en la oficina que falta una planta cuesta menos que descubrirlo frente a una puerta cerrada.
Guardado, sincronizado y revisado son estados diferentes
Un mensaje genérico de «todo correcto» puede esconder tres situaciones distintas: el cambio está en el dispositivo, ha llegado al sistema compartido o alguien lo ha validado.
Para una aplicación de campo proponemos comunicar estos estados de forma explícita:
- Guardado en este dispositivo: la información se ha almacenado localmente.
- Pendiente de sincronizar: falta transferirla al espacio compartido.
- Sincronizado: la transferencia se ha confirmado.
- Necesita revisión: existe una discrepancia que requiere una decisión.
No es necesario interrumpir cada acción con una notificación. Un indicador persistente y un detalle accesible pueden bastar. En cambio, si falla el guardado local, el aviso debe ser inmediato: la persona no puede marcharse pensando que su observación está a salvo.
Las fotografías requieren especial atención. El texto puede haberse enviado mientras quedan archivos pendientes. El estado del informe debe reflejar esa diferencia.
Sincronizar cambios exige decidir qué hacer con los desacuerdos
Dos técnicos pueden modificar la misma incidencia mientras están desconectados. Uno la marca como resuelta; otro adjunta evidencia de que continúa abierta. Recibir ambos cambios no explica por sí solo qué decisión tomar.
Los CRDT son estructuras de datos diseñadas para combinar cambios distribuidos. En Automerge, los conflictos de una propiedad pueden conservar valores concurrentes aunque se muestre uno de forma determinista. Esa convergencia técnica no decide qué estado es correcto para el negocio.
En nuestro ejemplo, tendría sentido conservar las fotografías, mostrar las dos valoraciones y solicitar revisión al responsable. En otros campos, una regla automática puede ser suficiente. Lo esencial es definirlo antes de desarrollar la sincronización.
No todos los proyectos necesitan un sistema colaborativo complejo. Asignar cada informe a un único editor y registrar las revisiones posteriores puede simplificar mucho una primera versión.
Los datos locales también necesitan protección y salida
Guardar cerca del usuario no convierte automáticamente la información en segura. En el diseño deben contemplarse dispositivos compartidos, bloqueo de acceso, cifrado cuando corresponda y recuperación ante pérdida del equipo.
En aplicaciones web hay además una limitación concreta: el almacenamiento del navegador tiene cuotas y puede eliminarse según sus políticas. MDN explica la persistencia y expulsión de datos. Solicitar almacenamiento persistente no equivale a tener una copia de seguridad.
Para el equipo de inspección, proponemos una exportación que incluya registros, fotografías originales y referencias entre ambos. Un PDF sirve para leer el informe; un formato estructurado facilita reutilizar sus datos.
La prueba útil consiste en exportar un expediente y reconstruirlo fuera de la aplicación. Si solo se recupera una imagen de la pantalla, el control de la información sigue siendo limitado.
Cómo comprobar si este enfoque merece la inversión
Antes de construir toda la herramienta, conviene ensayar un recorrido completo con una pequeña selección de informes y dispositivos reales:
- Preparar el material y activar el modo avión.
- Crear incidencias, adjuntar fotos y reiniciar la aplicación.
- Introducir un cambio contradictorio desde otro dispositivo.
- Recuperar la conexión y revisar transferencias y discrepancias.
- Exportar el resultado y comprobar que se entiende fuera del sistema.
En ese ensayo interesa medir cuánto tarda en confirmarse un guardado, qué información falta y cuántas veces alguien necesita repetir una acción. La ausencia de cobertura debe formar parte del escenario de uso habitual.
Una reserva de inventario compartido o una autorización central pueden requerir conexión para confirmarse. Identificar estas excepciones permite combinar autonomía local con controles comunes, sin prometer que cualquier operación estará disponible siempre.
Si tu equipo necesita trabajar en obra, en instalaciones o durante visitas técnicas, cuéntanos el flujo que quieres resolver. En Viseni podemos estudiar contigo qué tareas deberían completarse en el dispositivo y cómo convertir ese criterio en una aplicación útil.
