Plano de evolução tecnológica
Zum, a feira passa na sua porta · Equipe Beezes · Desafio ELI Agro 2026 · versão de 16/10/2026
1 · Hoje2 · Próximos 3 a 6 meses3 · 6 a 18 meses4 · Arquitetura5 · Custos6 · Riscos
Em uma frase: o Zum liga quem compra a quem vende hortifruti, na porta do morador ou no ponto da feira, com pedido antecipado e aviso de que o vendedor está chegando. O plano abaixo diz o que já roda, o que vem depois e o que precisamos para chegar lá.
1 · Estado atual (outubro de 2026)
O protótipo está em produção e é usado em teste por moradores e vendedores. Um único app, com dois perfis, para Android (APK) e iPhone (PWA).
| Camada | O que existe |
|---|---|
| App | Flutter (Dart), uma base de código para Android e web. Login por WhatsApp, abas por perfil, mapas, pedidos, rota, números do vendedor. PWA com service worker para abrir com sinal fraco. |
| API | NestJS (TypeScript) + Prisma, REST, validação por DTO, módulos por domínio: usuários, vendedores, produtos, paradas de rota, pedidos, mapas e acompanhamento. |
| Dados | PostgreSQL. Pedidos idempotentes (reenvio em rede ruim não duplica), valores em centavos, quantidades fracionadas (0,5 kg). |
| Mapas | Google Maps no app (Android e web). Geocodificação e rota otimizada pela API, atrás de interfaces, com cache e limite de uso por usuário. |
| Avisos | WhatsApp (Evolution API) com SMS como reserva. Aviso uma única vez quando o vendedor chega perto do endereço. |
| Entrega contínua | GitHub Actions: análise, testes, imagem Docker e deploy automático com verificação de saúde e volta atrás se falhar. Segredos no Doppler. |
| Qualidade | Testes automatizados no back (133) e no app (153), mais teste manual em celular real. |
Decisões de projeto que seguem valendo
- Internet intermitente: telas carregam antes de sair, requisições idempotentes, nada depende de conexão contínua.
- Celular simples e pouca familiaridade com app: poucos campos, texto curto, botões grandes, fonte grande do sistema sem quebrar a tela.
- Privacidade (LGPD): coleta só nome, contato e endereço, com consentimento no cadastro. A posição do vendedor só aparece para o morador com pedido a caminho, e a base do vendedor nunca é exposta (a lista mostra só uma região aproximada).
- Mapas sem expor chaves: chaves públicas no app, restritas por aplicativo; a chave de servidor fica só no back.
2 · Próximos 3 a 6 meses (v1.0)
| Item | Por que | Como |
|---|---|---|
| Ponto de venda e retirada | A pesquisa de 15/10 com vendedores de banca da CEASA e do Centro Administrativo mostrou demanda por reserva e organização de pedidos, sem rota. | Novo tipo de parada (“ponto”) com local, dias e horário; pedido com escolha entre receber em casa ou retirar; status “pronto para retirar”; aviso “estou no ponto”. Migração aditiva, sem quebrar o que existe. |
| Aviso por push (Android) | Hoje o aviso depende do WhatsApp. | Firebase Cloud Messaging; WhatsApp continua como reserva. |
| Modo offline | Vendedor trabalha com sinal ruim. | Guardar a lista do dia e a fila de ações no aparelho; sincronizar com idempotência. |
| Avaliação do vendedor | Confiança do morador. | Um toque após a entrega; média no perfil. |
| Pedido recorrente | Previsibilidade de demanda para o vendedor. | “Repetir toda semana” a partir de um pedido feito. |
| Observabilidade | Achar falhas antes do usuário. | Logs estruturados, alertas de saúde, backup e restauração testados do banco. |
Ainda não implementado: o ponto de venda e a retirada estão decididos e planejados; a implementação começa depois do demoday. A amostra da pesquisa é pequena (6 respostas, todas da CEASA), por isso validaremos com vendedores do Centro Administrativo antes de construir.
3 · De 6 a 18 meses (escala)
- Pagamento por Pix dentro do app, com taxa de conveniência. Hoje nenhum vendedor pesquisado pagaria mensalidade, então a receita vem de quem compra ou de parceiros.
- Painéis para cooperativas e poder público (UNICAFES, prefeituras): volume vendido, famílias atendidas, bairros, desperdício evitado. Dados agregados, sem exposição individual.
- Integração com programas institucionais (PAA e PNAE): pedidos recorrentes de instituições para a agricultura familiar.
- Cestas prontas (salada, sopa, semana) e catálogo de produtos de época.
- Mais cidades e vendedores: onboarding guiado, suporte e métricas por região.
- App nativo para iPhone, se a PWA limitar notificações e execução em segundo plano.
4 · Arquitetura alvo e o que muda em cada fase
HOJE (monólito modular)
App Flutter ──► API NestJS ──► PostgreSQL
│
├─► Google Maps (geocodificação e rotas)
└─► Evolution API ──► WhatsApp
v1.0 (+ avisos e offline)
App ──► API ──► PostgreSQL
├─► fila de mensagens (WhatsApp, push FCM, SMS)
├─► armazenamento de imagens de produtos
└─► Google Maps
ESCALA (+ pagamentos e painéis)
App ──► API (várias réplicas) ──► PostgreSQL (réplica de leitura)
├─► serviço de pagamentos (Pix)
├─► painéis (consultas agregadas)
└─► WhatsApp Business Platform (oficial)
- Princípio: continuar monólito modular enquanto a equipe for pequena; extrair um serviço só quando houver dor real.
- Integrações atrás de interfaces (mapas, mensagens): trocar de fornecedor não muda o resto do código. Já é assim hoje.
- Banco: índices geográficos (PostGIS) só se a busca por distância pesar; hoje o cálculo em memória atende o piloto.
5 · Custos por fase (estimativas a validar no piloto)
| Fase | Infra | Terceiros | Observação |
|---|---|---|---|
| Hoje (piloto) | Servidor já existente da equipe, sem custo adicional relevante | Google Maps dentro do nível gratuito com teto de uso e alerta de orçamento; WhatsApp por instância própria | Domínio e certificados gratuitos |
| v1.0 | Servidor dedicado para API e banco, com backup (ordem de algumas centenas de reais por mês) | Push gratuito; mensagens oficiais do WhatsApp cobradas por conversa; Maps conforme uso | Cobrar taxa de conveniência cobre este custo com poucas centenas de pedidos |
| Escala | Réplicas e banco gerenciado | Taxas de Pix e do WhatsApp oficial | Depende do volume; medir custo por pedido desde já |
Todos os valores acima são estimativas de ordem de grandeza. O piloto serve para medir o custo real por pedido antes de decidir preço.
6 · Riscos técnicos e como reduzi-los
| Risco | Impacto | Mitigação |
|---|---|---|
| WhatsApp pela Evolution API não é oficial: pode bloquear o número | Código de login e avisos param | SMS como reserva (interface pronta), push FCM em v1.0 e migração para a API oficial do WhatsApp na escala |
| Servidor e banco em um único lugar | Indisponibilidade total | Monitoramento, alertas de disco e saúde, backup testado, deploy com volta automática (já existe) |
| Custo do Google Maps crescer com o uso | Cobrança inesperada | Chaves restritas, cota diária, alerta de orçamento, cache de geocodificação e estimativa local quando a rota falha |
| Internet ruim no campo | Pedidos perdidos ou duplicados | Idempotência (já existe) e modo offline com fila |
| Privacidade da localização | Exposição de endereço do vendedor | Posição ao vivo só para quem tem pedido a caminho; região aproximada nas listas; opção de parar de compartilhar |
| Baixa familiaridade com app | Abandono | Fluxos curtos, texto simples, testes com usuários reais em cada versão |
| Equipe pequena | Ritmo e continuidade | Testes automatizados, documentação viva, deploy automático e padrões de código escritos |
Código-fonte e documentação ficam em repositórios privados da equipe e podem ser mostrados à banca.