Ter o sistema pronto no Figma resolvia metade do problema. A outra metade era fazer ele existir no produto.

Quando propus a migração, a reação do time de desenvolvimento foi imediata: eles já tinham o MUI rodando, integrado e testado, e por isso reconstruir tudo do zero em outra biblioteca soava como retrabalho puro, sem ganho proporcional ao esforço. E eles tinham razão em desconfiar: um Design System que só existe como documentação bonita no Figma, e que exige que cada componente seja recriado manualmente em código, tende a nascer defasado e morrer rápido.

Mas o MUI puro também tinha um custo que não aparecia à primeira vista: para adaptar os componentes padrão à marca da Accion, cada squad fazia seus próprios ajustes de estilo em cima da lib, como um botão customizado no Portal de Vendas, outro ligeiramente diferente no Portal do Cliente, outro nos fluxos da AIDA. Nenhum desvio isolado parecia grave, mas o acúmulo criava exatamente o tipo de inconsistência que um Design System deveria evitar: múltiplas versões do "mesmo" componente, sem uma fonte única de verdade entre design e código.

Desde o início, a intenção não foi de "desenhar componentes", nem "ser mais rápido que o MUI", e sim reduzir a distância entre o Figma e o código a praticamente zero, para que adotar o novo sistema custasse menos do que continuar convivendo com as variações informais que o MUI, sozinho, não impedia.