Design System: Why your component library is dying (and how we started saving it)

Augusto Sandim — Sat, 17 Jan 2026 13:16:03 +0000

Every frontend developer has been there: you receive a new prototype in Figma, open the project's component library, and realize that... nothing fits. The colors are slightly different, the spacing doesn't match up, and that "standard" button requires 15 extra lines of CSS just to resemble the design.

Over the last year, I lived exactly this scenario. What started as a robust React library over time became a productivity bottleneck and a museum of obsolete technical decisions.

In this first post, I want to share how we identified that our Design System (DS) was failing and why we decided to rebuild it as a multi-platform ecosystem.

The Diagnosis: The "Drift" Between Design and Code

The first warning sign was inconsistency. The Design team was evolving rapidly, testing new approaches and UX patterns. Meanwhile, our React library was stagnant.

This disconnect creates a dangerous phenomenon known as Shadow CSS. To deliver their tasks on deadline, developers stop using system components and start creating "local versions" or globally overriding styles.

Result? An ever-increasing bundle size, impossible maintenance, and an interface that looks like a patchwork quilt.

When Technology Becomes the Problem

In our case, we had a technical complication: the library was entirely based on styled-components in versions that were already becoming deprecated.

Although CSS-in-JS had its peak, we realized that the way it was implemented throughout the project generated:

Maintenance difficulty: Changing a basic behavior required navigating complex trees of styled components.
Barrier to entry: New stacks (like Mobile) couldn't leverage anything we had already done for Web.

We realized that just updating lib versions wasn't enough. We needed a Design System System (yes, a system to manage the system).

The Turning Point: From React to Multi-platform

The big decision was: stop building just for the Web and start building for the brand.

Our company doesn't live on React alone. We have native Android, iOS, Flutter, and Web. If we kept focusing only on a React library, the inconsistency problem would repeat itself on all other fronts.

The Monorepo Strategy

We decided to migrate to a **Monorepo **structure. The idea was to centralize the Design System's intelligence in a single place, but distribute it to all platforms:

Design Tokens: The Single Source of Truth.
Core Logic: Component business rules that could be shared.
Specific implementations: Dedicated packages for React, Flutter, and Native Mobile.

This changed the game. The Design System stopped being "that React button repository" to become the universal language of engineering at the company.

Why should you care about this?

If you are a Senior Software Developer, you know our job isn't just writing code, but ensuring the solution's maintainability and scalability. Keeping the connection alive between design and code brings clear benefits:

Reduces Time-to-Market: Fewer discussions about pixels, more focus on features.
Eliminates Technical Debt: Brand updates are propagated automatically through tokens.
Unifies the experience: The user feels they are using the same product, whether on the site or the app.

And you?

Have you ever felt like your Design System is hindering more than helping? Let's talk in the comments!

Por que o seu Design System está morrendo (e como começamos a salvá-lo)

Augusto Sandim — Tue, 13 Jan 2026 23:09:58 +0000

Todo desenvolvedor frontend já passou por isso: você recebe um protótipo novo no Figma, abre a biblioteca de componentes do projeto e percebe que... nada encaixa. As cores são levemente diferentes, os espaçamentos não batem e aquele botão que deveria ser "padrão" precisa de 15 linhas de CSS extra para ficar igual ao design.

No último ano, vivi exatamente esse cenário. O que começou como uma biblioteca React robusta, com o tempo, tornou-se um gargalo de produtividade e um museu de decisões técnicas obsoletas.

Neste primeiro post, quero compartilhar como identificamos que nosso Design System (DS) estava falhando e por que decidimos reconstruí-lo como um ecossistema multiplataforma.

O diagnóstico: A "Deriva" entre Design e Código

O primeiro sinal de alerta foi a inconsistência. O time de Design evoluía rápido, testando novas abordagens e padrões de UX. Enquanto isso, nossa biblioteca em React estava estagnada.

Essa desconexão cria um fenômeno perigoso: o Shadow CSS. Desenvolvedores, para entregarem suas tarefas no prazo, param de usar os componentes do sistema e começam a criar "versões locais" ou a sobrescrever estilos globalmente.

Resultado? Um bundle cada vez maior, manutenção impossível e uma interface que parece uma colcha de retalhos.

Quando a tecnologia se torna o problema

No nosso caso, tínhamos um complicador técnico: a biblioteca era inteiramente baseada em styled-components em versões que já estavam se tornando depreciadas.

Embora o CSS-in-JS tenha tido seu auge, percebemos que a forma como ele estava implementado no projeto inteiro gerava:

Dificuldade de manutenção: Alterar um comportamento básico exigia navegar por árvores complexas de componentes estilizados.
Barreira de entrada: Novas stacks (como Mobile) não podiam aproveitar nada do que já tínhamos feito para Web.

Percebemos que não bastava atualizar as versões das libs. Precisávamos de um Design System System (sim, um sistema para gerir o sistema).

A Virada de Chave: Do React para o Multiplataforma

A grande decisão foi: parar de construir apenas para Web e começar a construir para a marca.

Nossa empresa não vive só de React. Temos Android nativo, iOS, Flutter e Web. Se continuássemos focados apenas em uma biblioteca React, o problema da inconsistência se repetiria em todas as outras frentes.

A estratégia do Monorepo

Decidimos migrar para uma estrutura de Monorepo. A ideia era centralizar a inteligência do Design System em um único lugar, mas distribuir para todas as plataformas:

Design Tokens: A fonte única de verdade (Single Source of Truth).
Core Logic: Regras de negócio de componentes que poderiam ser compartilhadas.
Implementações específicas: Pacotes dedicados para React, Flutter e Mobile Nativo.

Isso mudou o jogo. O Design System deixou de ser "aquele repositório de botões em React" para se tornar a linguagem universal da engenharia na empresa.

Por que você deveria se importar com isso?

Se você é um Senior Software Developer, sabe que nosso trabalho não é apenas escrever código, mas garantir a manutenibilidade e a escalabilidade da solução. Manter a conexão viva entre design e código traz benefícios claros:

Reduz o Time-to-Market: Menos discussões sobre pixels, mais foco em funcionalidades.
Elimina o Débito Técnico: Atualizações de marca são propagadas automaticamente através de tokens.
Unifica a experiência: O usuário sente que está usando o mesmo produto, seja no site ou no app.

E você?

Já sentiu que seu Design System está mais atrapalhando do que ajudando?

DEV Community: Augusto Sandim