Projeto: Agriness Presence App

Introdução

Em 2022, assumi a liderança do time responsável pelo mobile do Presence App, um aplicativo offline-first construído com React Native, que auxilia técnicos agrícolas de grandes corporações a organizarem seu dia-a-dia, gerarem reports, controlarem KPIs ao atenderem granjas de múltiplos produtores. Neste post, compartilho a experiência, os desafios e as lições aprendidas ao longo desta jornada.

O contexto do projeto

O Presence App não é um app simples de coleta de dados. Ele faz parte da operação de campo de grandes empresas do agro, com técnicos que passam o dia entre granjas, checklists, indicadores, registros sanitários, agendando visitas e acompanhando resultados. Na maior parte do tempo, a conectividade é ruim ou simplesmente não existe, então o técnico não pode depender de internet para trabalhar.

Com isso, o app precisava ser confiável offline, tolerante a sincronizações atrasadas, resiliente a inconsistências e simples o suficiente para não atrapalhar a rotina de quem estava no campo tentando resolver problemas reais.

Meu papel como líder técnico

Quando assumi a liderança, meu papel rapidamente deixou de ser só o de programar features. Eu precisava organizar o trabalho técnico do time, melhorar a qualidade das entregas, reduzir regressões e, ao mesmo tempo, manter a evolução do produto em um cenário com bastante regra de negócio.

Em resumo, minhas atividades eram:

• liderar a arquitetura mobile do projeto em React Native
• orientar decisões de implementação com foco em estabilidade e manutenção
• apoiar o time na leitura e tradução das regras de negócio para código
• atacar problemas de performance, sincronização e confiabilidade
• estruturar um fluxo de desenvolvimento que permitisse evoluir o app sem virar refém dele

Foi um tipo de liderança muito mão na massa. Eu seguia implementando partes importantes do sistema, mas também gastava bastante energia destravando o time, revisando decisões arquiteturais e tentando evitar que soluções rápidas virassem problemas recorrentes alguns meses depois.

O desafio real: offline first de verdade

Muita gente usa "offline-first" como palavra bonita em apresentação. No Presence App, isso é exigência operacional.

O técnico pode registrar informações ao longo do dia inteiro sem conexão estável. Depois, em algum momento, o aplicativo precisa sincronizar tudo sem perder dados, sem duplicar eventos e sem deixar o usuário na dúvida sobre o que foi enviado ou não.

Isso traz uma série de problemas, como:

• fila de operações pendentes
• controle de status de sincronização
• tratamento de conflitos
• persistência local confiável
• feedback claro na interface para ações ainda não sincronizadas

Boa parte do trabalho mais valioso do projeto está aí. Não é o tipo de coisa que aparece em screenshot de portfólio, mas é o que define se o produto é usável ou não.

Decisões técnicas que fizeram diferença

Ao longo do projeto, trabalhamos sobre uma base em React Native com Expo no bare workflow, Redux Toolkit, persistência de estado e uma camada de serviços bem separada da interface. Isso ajuda bastante, mas também exige disciplina. Em apps com muita regra de negócio, qualquer descuido na organização do estado cobra caro depois.

Algumas decisões são especialmente importantes:

Centralizar estado e fluxos assíncronos com Redux

Com múltiplos domínios convivendo no mesmo app, como atendimento, calendários, lotes, checklists, indicadores e preferências do usuário, faz sentido manter previsibilidade no gerenciamento de estado. Redux Toolkit ajuda a reduzir boilerplate, mas o ganho real vem da clareza de fluxo. Fica mais fácil entender quem dispara cada ação, como os dados são persistidos e em que ponto a sincronização pode quebrar.

Separar regra de negócio da camada de tela

Esse é um ponto em que bato bastante. Tela não pode virar depósito de regra crítica. Sempre que a regra fica espalhada em componente, hook e callback de navegação, a manutenção piora e o risco de regressão sobe. Conforme o projeto evolui, empurramos mais responsabilidades para slices, serviços e fluxos mais previsíveis.

Cautela na sincronização dos dados

A sincronização dos dados é a parte central da experiência do app presence. Por isso, precisamos balancear bem o que precisa ser exibido ao usuário ou apenas mantido como plano de fundo. Coisas como "pendente de sincronização", "sincronizado" e "erro" precisam existir tanto no código quanto na interface. O usuário precisa entender o que está acontecendo sem depender de interpretação.

Melhorar coleta de erros e comportamentos em produção

Uma dor bastante grande que o time tinha quando entrei no projeto, era o fato de que muita coisa acontecia para o técnico sem o conhecimento da equipe. Erros, comportamentos estranhos, e ninguém sabia dizer o por quê. Não é como se o app não tivesse qualquer coleta de logs, o Sentry e o Amplitude estavam configurados, mas essas caras ajudam mais quando ocorre alguma exceção de código, não de regras de negócio.

Por conta disso, introduzi um sistema de logs de arquivo no app, que guardam informações ao longo de toda a utilização do app. Se alguma checklist estiver fora da vigência e mesmo assim aparecer como disponivel para aplicação para o usuário, com os logs do app nós podemos dizer o motivo disso ter acontecido. Isso agilizou em mais de 90% a velocidade de correções de incidentes no projeto.

Liderar também foi organizar o caos

Projetos longos normalmente acumulam camadas: feature urgente, ajuste rápido, workaround, tela que nasce pequena e cresce demais. O Presence App não foge disso.

Parte do meu trabalho é identificar onde a base está ficando frágil e ir atacando isso sem paralisar a entrega. Nem sempre dá para parar tudo e refatorar do jeito perfeito. Quase nunca, na verdade. Então a estratégia precisa ser mais pragmática: melhorar a estrutura enquanto o produto segue andando.

Isso envolveu decisões como:

• refatorar trechos críticos antes que virassem gargalo de evolução
• padronizar padrões de implementação entre diferentes módulos
• subir o nível das code reviews
• cobrar mais clareza em tipos, contratos e responsabilidades
• evitar que problemas de arquitetura fossem empurrados indefinidamente

Liderança técnica, para mim, tem muito disso. Não é só escolher stack ou aprovar pull request. É criar um ambiente em que o time consegue tomar boas decisões com mais frequência.

O lado humano do projeto

Esse tipo de produto ensina rápido que software não existe no vazio. O que parecia simples na descrição muitas vezes era confuso no uso real. O que parecia uma boa abstração no código podia não respeitar o fluxo mental de quem estava em atendimento no campo.

Por isso, uma parte importante da liderança é aproximar tecnologia e operação. Entender melhor o contexto do usuário ajuda a reduzir soluções artificiais. Em vez de perguntar só "como implementar?", a pergunta certa muitas vezes é "como essa pessoa trabalha quando o dia sai do roteiro?".

Essa mudança de perspectiva melhora muita coisa. Melhora a interface, melhora a tolerância a erro e melhora até a priorização técnica.

O que levo dessa experiência

Liderar o Presence App consolida algumas convicções minhas como desenvolvedor React Native sênior.

A primeira é que confiabilidade vale mais do que sofisticação visual quando o app sustenta operação de campo. Se o usuário não confia no que foi salvo, sincronizado ou enviado, o resto perde valor.

A segunda é que arquitetura boa não é a mais "bonita". É a que ajuda o time a evoluir o produto com menos risco. Em projetos com muita regra de negócio, legibilidade e previsibilidade vencem genialidade quase sempre.

A terceira é que liderança técnica de verdade exige contexto. Não adianta tomar decisão só olhando para código. É preciso entender produto, operação, restrições do time e impacto de longo prazo.

Fechamento

Olho para esse projeto como um dos trabalhos mais completos da minha trajetória até aqui. Ele exige repertório técnico, capacidade de execução, leitura de produto e maturidade para liderar decisões em um ambiente com bastante complexidade.

Mais do que entregar funcionalidades, o desafio é construir confiança. Confiança do usuário no app, confiança do time na base de código e confiança da operação de que o mobile aguenta o peso do dia a dia.

É esse tipo de problema que me faz crescer como líder técnico. E, honestamente, é esse tipo de projeto que eu mais gosto de tocar.