Pular para o conteúdo
Voltar

CRM Loja

Em produçãoPapel: Desenvolvedor principalFlutterRiverpodSupabaseKotlin

App Flutter de vendas e pré-faturamento da equipe comercial do Grupo Coagro: clientes, catálogo, orçamentos, pedidos e metas, lendo o ERP Winthor — em produção no Android e na web.

CRM Loja

// Visão geral

O CRM de campo da Coagro. O vendedor de insumos consulta cliente, histórico de compra, limite de crédito e produto disponível, monta orçamento e pedido, acompanha o pré-faturamento e as metas — no celular, na propriedade, ou no navegador da loja.

// O desafio

O ERP registra o pedido, mas não a conversa que leva até ele: visita, diagnóstico da lavoura, proposta, negociação. Isso morava na cabeça e no caderno do vendedor — e saía de férias com ele. O app ainda precisava funcionar no 4G da fazenda, ser atualizado numa frota de aparelhos sem loja de apps e não podia duplicar o dado que já tem dono no Winthor.

// Restrições

Funcionar no 4G da fazenda, ser atualizado numa frota de aparelhos sem loja de apps e nunca duplicar o dado que já tem dono no ERP Winthor.

// Decisões de engenharia

Uma fonte de verdade por dado

Escolha
o que já é verdade no ERP é lido do Winthor; só o que ainda não virou pedido mora no Supabase.
Por quê
o pedido tem dono no ERP — uma cópia no app divergiria dele.
Trade-off
duas origens de dados para o app conciliar, em vez de uma base única.

Atualização sem loja

Escolha
canal nativo em Kotlin que baixa o APK em segundo plano e confere o SHA-256 antes de instalar.
Por quê
a frota de aparelhos da empresa não passa por loja de apps.
Trade-off
código nativo Android para manter além do Flutter.

// A solução

Flutter com Riverpod e Clean Architecture por funcionalidade (domínio, dados, apresentação), com as regras de camada verificadas por um script no CI. O que já é verdade no ERP é lido do Winthor; o que ainda não virou pedido mora no Supabase, com RLS, triggers e RPCs no Postgres. A atualização do APK é feita pelo próprio app, por um canal nativo em Kotlin, com download em segundo plano e verificação SHA-256; e as notificações do chat chegam com o app fechado, sem Firebase, por um serviço Android em primeiro plano.

// Arquitetura

Diagrama da arquitetura do CRM Loja. O app Flutter (Android e web), com Riverpod e Clean Architecture por funcionalidade em domínio, dados e apresentação, fala com duas origens: lê do ERP Winthor o que já é verdade no ERP, e grava no Supabase (Postgres com RLS, triggers e RPCs) o que ainda não virou pedido. No Android, um canal nativo em Kotlin baixa o APK novo em segundo plano e confere o SHA-256, e um serviço em primeiro plano entrega as notificações do chat sem Firebase. No CI, um script verifica as regras de camada.

Meu papel

Desenvolvedor principal (cerca de 95% dos commits): arquitetura, app, banco (190+ migrations), código nativo Android, testes e pipeline de release. Sistema do Grupo Coagro, desenvolvido em parceria com a NWERP.

Tecnologias

FlutterDartRiverpodgo_routerSupabasePostgreSQLKotlinGitHub Actions

// Telas

Tela inicial: vendas do dia, ação recomendada do dia e meta do mês
Fazer pedido: tabela de produtos com promoções, estoque por lote e filial
Produto bloqueado para consumidor final, sem estoque e com vários lotes
Menu lateral: clientes, produtos, chat, pedidos, gestão, receituário e autorizações
Login do Portal do Vendedor

// Resultado e evidências

Em produção na equipe comercial, no Android e na web, com mais de 260 versões publicadas pelo Release Please e mais de 800 arquivos de teste (9 mil+ casos) — a suíte completa roda toda noite no CI. Em 2026 ganhou gamificação comercial (liga, missões, conquistas e recompensas, que nunca bloqueia uma venda) e chat com push nativo em Kotlin, com cliente próprio do Supabase Realtime e resposta direto pela notificação.

versões publicadas
260+
releases pelo Release Please
arquivos de teste
800+
a suíte completa roda toda noite no CI
migrations no Supabase
190+
dos commits
~95%

Gostou deste tipo de trabalho?