Case · Desenvolvimento sob Demanda

Rangoo Delivery — ArcelorMittal Tubarão

Sistema de gestão de entregas desenvolvido do zero para uma das maiores siderúrgicas do Brasil. Do discovery ao produto em produção, com squad enxuto e evolução contínua.

Zero
soluções prontas que atendiam a demanda
Squad
enxuto do discovery ao produto
SaaS
modelo de receita recorrente

Uma operação logística complexa que nenhum software pronto resolvia.

A ArcelorMittal Tubarão é uma das maiores siderúrgicas do Brasil, com uma operação logística que envolve múltiplos fornecedores, rotas e controles de entrega espalhados por diferentes times.

A demanda chegou porque já tinham tentado adaptar ferramentas genéricas — sem sucesso. O problema era específico demais para soluções de prateleira. Precisavam de algo construído para a realidade deles, não do contrário.

O projeto entrou pela Future Ventures: descoberta aprofundada do problema antes de qualquer decisão técnica, seguida de desenvolvimento iterativo com squad enxuto e entrega incremental — sem big bang no final.

Setor
Indústria Siderúrgica
Porte
Grande porte · B2B
Duração
Em evolução contínua
Atuação
Discovery, arquitetura, desenvolvimento e evolução

O que tornava esse problema difícil de resolver.

A operação de entregas da ArcelorMittal não era apenas grande — era heterogênea. Fornecedores diferentes, regras diferentes, times diferentes. Nenhuma ferramenta genérica conseguia modelar essa complexidade sem virar um projeto de customização infinita.

📋
Gestão manual e fragmentada Escalas de entrega controladas por planilhas descentralizadas. Cada time com sua versão, sem sincronização e sem histórico confiável.
👁
Sem visibilidade da operação Nenhuma visão centralizada do status das entregas. Para saber o que estava acontecendo, era preciso ligar ou mandar mensagem — em tempo real.
🔗
Sem integração entre áreas Times de logística, operação e fornecedores operando em silos. Informação que precisava chegar em três lugares chegava em um — ou em nenhum.
🧩
Nenhuma solução pronta que servisse Sistemas de gestão de entregas do mercado foram avaliados e descartados. A especificidade da operação exigia algo construído do zero — ou adaptações tão profundas que equivaliam a isso.

Do discovery ao produto em produção.

O projeto seguiu o modelo da Future Ventures: o trabalho começa pelo entendimento do problema real, não pela tecnologia. Só depois de mapear a operação em profundidade é que a arquitetura foi definida — e o desenvolvimento, iniciado.

Fase 01 · Discovery

Imersão na operação

Entrevistas com operadores, gestores e fornecedores para entender o fluxo real de entregas — não o fluxo documentado. Mapeamento de regras, exceções e pontos de fricção que nunca apareceriam num briefing.

Fase 02 · Arquitetura

Definição da solução

Escolha de stack, modelagem de dados, definição de módulos e escopo do MVP. O objetivo era resolver o problema central primeiro — e construir a base certa para evoluir depois.

Fase 03 · Build iterativo

Desenvolvimento incremental

Squad enxuto, ciclos curtos, validação contínua com o time da ArcelorMittal. Cada entrega parcial em produção antes de seguir para o próximo módulo — sem acumular risco.

Fase 04 · Evolução contínua

Produto em operação

O sistema entrou em produção e segue evoluindo. Novas funcionalidades são priorizadas com base no uso real — não em roadmaps definidos no início do projeto.

O que o sistema entrega hoje.

100%

Visibilidade da operação

Gestores têm visão centralizada e em tempo real de todas as entregas — algo que antes dependia de ligações e planilhas atualizadas manualmente.

Zero

Planilhas no processo crítico

O controle manual foi eliminado do fluxo principal. A operação roda pelo sistema — com histórico, rastreabilidade e dados confiáveis.

SaaS

Contrato recorrente

O modelo não foi de entrega pontual. É uma solução que evolui junto com a operação do cliente — com receita recorrente e relação de longo prazo.

O Rangoo Delivery não foi um projeto que terminou na entrega. É um produto que continua sendo desenvolvido, com novas funcionalidades sendo priorizadas com base no uso real da operação.

O que esse projeto confirma.

01

Discovery não é opcional em projetos complexos

Projetos que pulam a fase de descoberta para economizar tempo quase sempre pagam mais caro depois — em retrabalho, funcionalidades erradas e arquitetura que não escala. A imersão no problema real é o trabalho mais importante.

02

Entregas incrementais reduzem risco e aumentam confiança

Cada módulo entregue em produção antes do próximo ser iniciado cria um ciclo de validação contínua. O cliente vê progresso real, a equipe aprende com o uso e os riscos ficam controlados.

03

O modelo certo é contínuo, não pontual

Sistemas de operação não terminam — evoluem. Um modelo de contrato recorrente alinha os incentivos certos: a solução só funciona de verdade se continuar funcionando, e isso exige evolução constante.

Tem um problema que nenhuma ferramenta pronta resolve?

Esse é o tipo de projeto que fazemos. Se você tem uma demanda específica de operação que soluções genéricas não atendem — fale comigo.

Fale comigo → Veja como trabalho

Projetos de desenvolvimento sob demanda têm ticket alto e modelo recorrente. Aceito novos projetos quando o perfil faz sentido.