Case study técnico
Da dor real à arquitetura: como um fechamento de caixa feito à mão virou um MVP em uso diário e agora um SaaS multi-tenant em desenvolvimento.
O código do SaaS é privado. Esta página e o repositório do case study mostram o raciocínio por trás dele (arquitetura, decisões e segurança), não a implementação.
Pequenos e médios negócios fecham o dia numa planilha e não têm equipe técnica para transformá-la em informação útil, na hora certa.
Lê a planilha do negócio, aplica os filtros configurados e envia o resumo formatado pelo WhatsApp, sem intervenção manual.
Cada fechamento vira um registro no banco relacional, e a planilha original fica preservada no armazenamento de objetos.
Todo dado pertence a um tenant, do schema do banco até a API. Um negócio nunca enxerga o outro.
Implantado na Pollo Loko, em São José dos Campos. Lê as planilhas do PDV, processa com Pandas e gera o relatório do dia pronto para o WhatsApp, distribuído como executável portátil. Reduziu o fechamento de caixa de 20 minutos para cerca de 30 segundos e está em uso diário desde o lançamento. Os requisitos foram levantados direto com o cliente, com manutenção contínua desde então.
A partir da validação do MVP, qualquer negócio poderá configurar seus filtros e seu template de mensagem, enviar a planilha e receber o resumo no WhatsApp.
10 de 11 sprints concluídos. Falta a sprint de cobrança, deploy e onboarding. O envio real de mensagens já foi testado ponta a ponta, com entrega confirmada no WhatsApp.
Cinco decisões representativas, cada uma detalhada como ADR no repositório.
Cookie httpOnly, CSRF double-submit e allowlist de sessão no Redis, para que uma sessão possa ser revogada de verdade antes de o token expirar.
Quando a Meta reclassifica a categoria de um template, o sistema guarda a categoria pedida e a efetiva como fontes de verdade distintas, com histórico.
Fila no Celery, retry automático e rastro persistido de toda tentativa, com sucesso ou falha. Nada é descartado em silêncio.
Ciclos dedicados de revisão, cada um com achado, correção e teste de verificação documentados, e não uma auditoria única no fim.
Todo dado tem tenant_id, e toda rota autenticada filtra por ele a partir do JWT, nunca de parâmetro da requisição. Sem exceção.
O produto funcionando de ponta a ponta. As mídias vêm do repositório do case study.
Sessão por cookie httpOnly, com verificação TOTP como segunda etapa.
Upload da planilha de referência com detecção automática de colunas, condições compostas, variáveis clicáveis e preview em tempo real antes do envio.
Template aprovado pela Meta e pipeline validado da planilha até a mensagem chegar. Telefones e destinatários são valores de teste, nunca dado real de cliente.
Todo push passa por um pipeline com lint, aplicação do schema do banco e testes, com cobertura mínima travada.
O pipeline roda ruff e depois pytest --cov. A régua de cobertura sobe junto com os testes novos, em vez de perseguir um número bonito sem substância.
fechabot-case-study/ ├── README.md visão geral ├── architecture/ diagramas e visão geral ├── decisions/ ADRs: decisões, alternativas, trade-offs ├── security/ achado, correção e verificação ├── roadmap/ feito, pendente, débitos técnicos └── media/ telas, diagramas e GIFs
O case study é público. Para uma demonstração ao vivo, me chame.