Como desenvolvemos um app offline que eliminou 2 dias de atraso na entrega de relatórios de campo. Um relato honesto do projeto, dos problemas que apareceram e do que funcionou.
Tem uma coisa que me incomoda profundamente em projetos de tecnologia: a distância entre o que o cliente acredita que precisa e o que de fato resolve o problema. Nesse projeto, o cliente chegou dizendo que queria “modernizar o processo de coleta”. Traduzindo: queria um app bonitinho.
O que ele precisava era bem diferente.
A empresa tinha equipes em campo coletando dados — inspeções, checagens de estoque, registros de ocorrências. Tudo era feito no papel, depois digitado no sistema. Resultado: os dados chegavam no escritório com dois dias de atraso. D+2.
Parece pouco? Não é. Nessa operação, D+2 significava tomar decisões com informações velhas. Estoque reposicionado tarde. Problemas detectados depois que já tinham se agravado. Retrabalho constante.
A lista de problemas que isso gerava era grande. E o mais irritante: todo mundo sabia que estava errado, mas ninguém conseguia resolver porque “sempre foi assim”.
Minha primeira proposta foi um formulário web. Simples, rápido de entregar. O cliente aprovou.
Problema: grande parte da coleta acontece em áreas com sinal ruim ou sem sinal nenhum. Formulário web virou pesadelo offline. Fomos para a segunda tentativa: um app com cache local.
Funcionou melhor, mas a sincronização era frágil. Quando o usuário voltava para área com sinal, nem sempre os dados subiam direito. Tivemos conflitos, dados duplicados, registros perdidos.
Terceira tentativa, dessa vez com uma abordagem offline-first de verdade. O app assume que não tem internet. Tudo é salvo localmente primeiro. A sincronização acontece em background, com controle de conflitos e fila de envio. A conectividade é bônus, não requisito.
Essa versão funcionou.
O app foi desenvolvido para Android (a maioria dos dispositivos em campo era Android de entrada). Usamos armazenamento local com SQLite, sync via API REST quando há conexão, e uma fila de upload com retry automático.
A parte mais trabalhosa não foi o código — foi o mapeamento dos formulários. Cada tipo de coleta tinha campos diferentes, validações diferentes, fotos opcionais ou obrigatórias em contextos diferentes. Gastamos mais tempo nisso do que no desenvolvimento em si.
A integração com o sistema de gestão da empresa veio depois. Eles tinham um ERP legado com uma API meio torta, mas deu para conectar.
Primeira semana foi caótica. Os usuários de campo tinham entre 40 e 60 anos, não eram familiarizados com app nenhum. Treinamento presencial foi obrigatório. Fizemos 3 rodadas.
Na segunda semana, os dados já chegavam no mesmo dia da coleta. D+0.
Na terceira semana, o gestor me ligou para dizer que tinha detectado um problema em uma unidade que, no modelo antigo, só teria aparecido dois dias depois já com consequências sérias.
Esse telefonema valeu mais do que qualquer relatório de entrega.
Primeiro: aplicativos para usuários não técnicos precisam ser absurdamente simples. Cada campo a mais é resistência a mais. Cada botão a mais é dúvida a mais.
Segundo: offline-first não é diferencial — é requisito. Se o app depende de internet para funcionar em campo, ele não serve para campo.
Terceiro: o treinamento é parte do projeto, não um extra. Subestimei isso no início e paguei o preço na primeira semana.
O projeto saiu das 6 semanas previstas para 8. Vale ter mencionado. Mas os resultados justificaram.
Se você tem operação em campo com coleta manual de dados, esse modelo funciona. O D+2 é um problema com solução conhecida.
30 minutos para entender o seu desafio e ver se faz sentido trabalharmos juntos.