Un técnico abre un tablero en un subsuelo, un repartidor entrega en una zona rural, un supervisor recorre un depósito con paredes de chapa. En los tres casos la señal desaparece justo cuando hay que cargar algo. Si la app necesita red para guardar, la persona deja de usarla: completa en papel, carga de memoria más tarde o directamente no carga. Esta guía explica cómo se diseña una app que sigue funcionando sin señal, con un caso real de servicio técnico.
Qué es una app offline-first
Una app offline-first está pensada para funcionar sin conexión como situación normal, no como excepción. La diferencia con un «modo sin conexión» agregado al final es de fondo:
- Guarda primero en el teléfono. Cada acción se escribe en una base de datos local y la pantalla responde al instante, haya red o no.
- Sincroniza después. Cuando vuelve la señal, lo pendiente viaja solo al servidor, sin que la persona toque nada.
- Resuelve los choques. Si la oficina y el campo cambiaron lo mismo, hay reglas claras para decidir qué versión queda.
Una app que «funciona offline» pero muestra un error al guardar, o que pierde lo cargado si se cierra, no es offline-first: es una app online con paciencia.
Cuándo la necesitás
No toda app tiene que funcionar sin señal. Conviene cuando se da alguna de estas situaciones:
- El trabajo se hace en salas de máquinas, subsuelos, azoteas o depósitos, donde la señal es mala o no existe.
- Hay recorridos por rutas o zonas rurales: logística, distribución, relevamientos de campo.
- El dato se pierde si no se carga en el momento: firmas, fotos, lecturas, repuestos usados.
- Ya probaste una app de mercado y los usuarios volvieron al papel porque «se cuelga cuando no hay señal».
Si tu equipo trabaja siempre en una oficina con wifi, una app web común alcanza y es más simple de mantener.
Por qué fallan las apps de mercado en campo
En el caso de una empresa de servicio técnico de climatización con 34 técnicos y unos 3.800 equipos instalados, el problema era exactamente este. Ya habían probado una app de mercado, pero los equipos estaban en salas de máquinas y azoteas sin señal. La app necesitaba red para guardar, así que el técnico completaba el parte afuera, de memoria, o volvía al papel. Resultado: el parte llegaba a la base dos días después, uno de cada tres volvía sin firma del cliente y los repuestos se descontaban del stock a fin de mes.
Cómo se diseña: cinco decisiones
Lo que separa una app que aguanta el campo de una que no son estas cinco decisiones, tomadas desde el primer día y no agregadas al final.
1. La base local es la fuente de verdad
Mientras no hay red, manda lo que está en el teléfono. La app guarda cada acción en una base de datos local (en el caso, SQLite) y nunca espera al servidor para responder. Si el técnico está en un subsuelo, la app lo muestra con una banda ámbar —«Sin conexión · guardado local»— y sigue funcionando exactamente igual.
2. Cada acción entra a una cola
Abrir la orden, tildar un control, cargar un repuesto, capturar la firma: cada operación se escribe en la base local y entra a una cola de sincronización con un identificador único. Cuando vuelve la señal —en el ascensor, en la calle, en el próximo cliente— un proceso en segundo plano vacía la cola sin que la persona haga nada.
3. Sincronización idempotente
Las conexiones en campo se cortan a mitad de camino. Si el teléfono manda dos veces la misma operación porque no recibió la respuesta, el servidor la reconoce por su identificador y no la duplica. Sin esto aparecen órdenes repetidas, repuestos descontados dos veces y firmas duplicadas.
4. Conflictos con reglas por campo
El caso difícil: la oficina reasigna una orden a otro técnico mientras el primero ya está trabajando sin señal. Cuando llega la sincronización, el sistema no pisa ninguna versión a ciegas. Aplica reglas por campo, no por orden completa: la asignación la decide la central, pero el contenido del parte, los repuestos y la firma los decide el campo, porque son lo que pasó de verdad. El panel muestra las dos versiones y deja revisar.
5. Fotos y archivos por separado
Las fotos pesan mucho más que los datos. Conviene que viajen aparte, comprimidas, y que la orden pueda quedar cerrada aunque las imágenes todavía estén subiendo. Así una conexión débil alcanza para cerrar el trabajo.
Qué cambió en el caso real
La app se construyó con el modo sin conexión primero: se arrancó con una sola familia de equipos y seis técnicos, probando en modo avión desde la primera semana. Tampoco se digitalizó el parte de papel tal cual: se armó un checklist por tipo de equipo con los controles que los técnicos miraban de verdad. A los cinco meses, los números eran estos:
| Indicador | Antes | Después |
|---|---|---|
| Cierre del parte | 2 días | Mismo día |
| Partes sin firma del cliente | 31% | 2% |
| Repuestos sin descontar a fin de mes | 18% | 0% |
| Segundas visitas por falta de historial | 14% | 5% |
El mismo patrón —tomar el dato en el lugar y sincronizarlo cuando hay red— es el que usa el sistema de control horario con reconocimiento facial.
Con qué tecnología se hace
No hay una sola respuesta, pero las piezas son siempre las mismas: una app móvil con base de datos local, una cola de sincronización y una API que acepte cada operación una sola vez. En el caso se usó React Native con SQLite en el teléfono, una API REST en Node.js y PostgreSQL en el servidor. Flutter o una app nativa en Kotlin también sirven; lo que define el resultado es la arquitectura, no el framework.
Errores comunes
- Agregar el modo sin conexión al final. Si la app se pensó online, cada pantalla supone que hay red y rehacerlo cuesta casi lo mismo que empezar de nuevo.
- Probar sólo con buena señal. Hay que probar en modo avión, en subsuelos y con la conexión cortándose a mitad de un envío.
- Resolver conflictos con «gana el último». Así se pierden firmas y repuestos sin que nadie se entere.
- Copiar el formulario de papel. Es la oportunidad de quedarse sólo con los controles que importan.
- No mostrar qué falta sincronizar. El técnico y la oficina tienen que ver cuántas operaciones siguen en el teléfono.
Checklist antes de arrancar
- Listá dónde se trabaja y dónde se corta la señal.
- Definí qué datos no se pueden perder: firma, fotos, repuestos, lecturas.
- Decidí, campo por campo, quién gana en un conflicto: la central o el campo.
- Elegí con qué grupo y qué tipo de trabajo empezar, y probalo en modo avión desde la primera semana.
- Prevé cómo se conecta con tu sistema de gestión para facturar y descontar stock sin recargar nada.
Cómo te ayudamos desde Intway
Desarrollamos apps a medida para equipos en campo, pensadas para funcionar sin señal desde el primer día, con su panel para la oficina y la integración con tu sistema de gestión. Mirá el caso completo de las órdenes de trabajo, cómo trabajamos en software para mantenimiento y servicio técnico y en logística y transporte, o cómo encaramos un software a medida para pymes.