O briefing parecia dez e tantas telas: listas de clientes, arquivos de documentos, gestão de perfil, views de admin. Construído tela a tela, isso vira dez e tantos conjuntos de código de tabela feitos sob medida e dez e tantas interpretações do mesmo design system. Então inverti — a entrega era uma biblioteca de componentes primeiro, e cada seção virou uma montagem de peças que já existiam.

Uns quinze componentes carregaram o portal inteiro: tabelas de dados ordenáveis, uma sidenav deslizante, grupos de botões em abas, filtros dropdown, modais, paginação, um campo de telefone com tratamento de país. Cada um foi construído uma vez, contra o design system, responsivo por padrão — então um ajuste na tabela melhorava toda seção que a usava, e consistência deixou de ser assunto de code review.

O backend tinha cronograma próprio, então o frontend foi construído contra dados mock no formato das respostas acordadas. Manteve os dois times andando em paralelo e obrigou os componentes a serem honestos sobre os estados — vazio, carregando, erro, uma linha, duzentas linhas — porque o mock produzia todos sob demanda, muito antes de um endpoint real conseguir.

Dois públicos dividem o codebase: o pessoal que administra as contas e os clientes que usam as próprias. Mesma biblioteca, mesma gramática de interação, permissões e densidade diferentes — o que fez o lado admin herdar de graça o acabamento do lado voltado ao cliente, em vez de acabar como o back office abandonado de sempre.