DEV Community: Guilherme Marucchi

Regra escrita é regra que falha

Guilherme Marucchi — Thu, 17 Sep 2026 13:15:13 +0000

Toda migração grande produz uma pilha de "não faça X".

Não misture os dois padrões no mesmo arquivo. Não crie mais arquivo no formato antigo. Não coloque componente
novo dentro de tela velha. Não use valor de cor direto, use o token.

Escrevemos essas regras num documento, com o motivo de cada uma, numeradas e datadas. O documento ficou bom.

E eu sei exatamente o que acontece com ele: alguém lê na primeira semana, ninguém lê na terceira, e em dois
meses uma pessoa nova entra no time e viola três regras no primeiro dia. Sem má vontade, sem descuido, só
por não saber que existiam.

Documento não escala. Ferramenta escala.

Isto é sobre o que aconteceu quando paramos de escrever regras e começamos a fazer as ferramentas recusarem.

A regra que virou verificação de build

A regra mais importante da migração era: os dois design systems não se misturam no mesmo arquivo.

O motivo é real. Os dois geram classes CSS com a mesma especificidade, e quando duas regras empatam quem
vence é decidido por ordem de injeção. Que muda entre ambiente de desenvolvimento e build de produção. O
resultado é aquele bug que funciona na sua máquina e quebra em produção, e que ninguém reproduz.

Isso ficou escrito no documento por semanas. Dependia de todo mundo lembrar.

Aí, corrigindo um problema completamente diferente, restringimos onde a ferramenta de CSS pode procurar
classes. Ela passou a olhar só o diretório do código novo, em vez do projeto inteiro.

O efeito colateral foi melhor que a correção: classe do padrão novo escrita dentro de um arquivo do padrão
antigo simplesmente não é gerada. O componente aparece sem estilo nenhum. A pessoa percebe na hora, antes
de commitar, sem ter lido regra nenhuma.

A regra saiu do documento e virou comportamento de build.

A regra que virou recusa da ferramenta

A segunda regra: migração acontece por bloco completo. Uma tela inteira por vez, nunca um componente
solto dentro de uma tela antiga.

O motivo é o mesmo de antes. Um componente novo dentro de um container antigo é exatamente a mistura que a
primeira regra proíbe.

O projeto tem um gerador de componentes: você roda um comando, responde onde quer criar, e ele monta a
estrutura de arquivos. Todo mundo usa, porque é mais rápido que criar à mão.

Colocamos a regra ali dentro. Hoje, se você tenta criar um componente dentro de uma tela que ainda não foi
migrada, o gerador para antes de criar qualquer arquivo:

A tela "x" ainda nao foi migrada para o design system novo.
Criar componente novo dentro de tela legada viola a regra de migracao
por bloco completo. Ver o documento de migracao.

Repare no que mudou. Antes, a regra dependia de a pessoa conhecer o documento. Agora, a ferramenta a
apresenta no exato momento em que ela é relevante e explica o porquê, para não parecer arbitrária.

E tem um ganho que não estava planejado: como a ferramenta precisa saber quais telas foram migradas, essa
lista virou um dado real no projeto, em vez de conhecimento na cabeça de alguém. A lista de configuração
passou a ser o registro do que já mudou.

O contra-exemplo: a regra que continuou só escrita

Uma das regras não tem nenhuma ferramenta atrás: nenhum arquivo novo no formato antigo.

O indicador da migração é a contagem desses arquivos. Ele só deveria descer.

Fui conferir depois de algumas semanas. Tinha subido: de 437 para 449.

Não era vazamento da fronteira. Eram doze arquivos nascidos em funcionalidades que já estavam na esteira de
produção, começadas antes de a fundação existir. Dez deles numa tela inteiramente nova, construída em
paralelo enquanto eu preparava a base.

Nada disso é erro de ninguém. É a consequência de migrar um sistema sem parar a entrega. De um lado
alguém prepara a fundação, do outro o produto continua saindo. Foi uma decisão, não um acidente.

Mas o número deixou clara a diferença entre as duas categorias de regra:

Regra	Estado
Não misture os padrões	ferramenta recusa
Não crie componente em tela não migrada	ferramenta recusa
Não crie arquivo no formato antigo	só documento

Adivinha qual foi violada.

A regra escrita que funcionou, porque tinha prazo

Não é que documento nunca sirva. Serve como base.

O menu novo tem 21 itens, e por semanas alguns não tinham destino definido. Em vez de deixar o link vazio,
criamos uma constante com nome próprio:

export const ROTA_PENDENTE = '#'

O comentário dela dizia o que fazer com ela: grep ROTA_PENDENTE src lista o que ainda falta, e essa é a
lista de trabalho da task de rotas.

Convenção pura. Nenhuma ferramenta atrás, dependendo de alguém rodar o grep. E funcionou, por um motivo que
as outras regras escritas não tinham: ela era autoliquidante. Cada item que ganhava destino saía da lista.
Quando o último saiu, a constante não tinha mais razão de existir, e apaguei ela junto com o ramo de código
que ela sustentava.

A vigilância não desapareceu. Mudou de forma:

todosOsItens.forEach((item) =>
  expect(item.rota).toMatch(/^(\/app|https:\/\/)/)
)

Item novo que entre com atalho, string vazia ou qualquer marcador de pendência quebra esse teste. Mesma
proteção, agora sem depender de ninguém lembrar de nada.

A diferença entre esta regra e a que foi violada é o prazo. Regra escrita para valer enquanto a migração
durar é aposta na memória do time, e essa aposta perde. Regra escrita para valer até uma lista zerar é
combinado com data, e data se cumpre.

Quando não transformar a regra em bloqueio

Aqui está a parte que eu quase errei.

Bloquear a terceira regra é trivial. Cinco linhas num hook de commit resolvem:

git diff --cached --name-only --diff-filter=A | grep '\.styles\.ts$' && exit 1

Não fiz. E o motivo vale mais que a técnica.

A primeira regra diz que componente novo não pode viver dentro de tela antiga. Então, se alguém precisa
acrescentar um componente a uma tela legada e o formato antigo estiver bloqueado, sobram duas opções:
migrar a tela inteira antes ou ficar travado.

Migrar uma tela inteira pode ser semanas de trabalho não planejado, no meio de uma entrega com data.

Ou seja: o bloqueio técnico transferiria um custo grande para pessoas que não participaram da decisão. Isso
não é ajuste de ferramenta, é mudança de política de entrega. Política se acorda, não se impõe por um
hook que aparece um dia sem aviso.

O critério que eu extraí disso: transforme a regra em bloqueio quando cumprir a regra custa quase nada.
Quando cumprir custa caro, o bloqueio precisa vir depois do acordo, não no lugar dele.

Guardrail imposto sobre custo alto não produz conformidade. Produz gente procurando como contornar. E quem
contorna uma vez contorna sempre.

O dia em que o guardrail me barrou

Vale contar a vez em que ele me pegou, porque minha primeira reação estava errada.

O pre-commit barrou um commit meu pelo mínimo de cobertura: 66,66% de linhas contra os 70% exigidos.

Achei que era formalidade. Eu tinha mexido em três drawers de uma tela, e os testes que já existiam
renderizavam todos eles. Fui olhar o relatório inteiro: cobertura de funções em 40%.

Os testes montavam os drawers e paravam ali. Nenhum clicava em fechar. Então os três callbacks que avisam
qual drawer foi fechado nunca tinham sido executados uma única vez. Se alguém trocasse as chaves entre si,
fechar um drawer fecharia outro, e a suíte continuaria verde.

Escrevi cinco testes. A cobertura foi para 85,71%, e um deles hoje afirma exatamente aquilo: cada botão de
fechar avisa a chave certa.

O hook não me barrou por formalidade. Me barrou porque faltava teste de verdade, e a porcentagem era o único
sintoma visível de uma falha que eu não tinha percebido lendo o código.

Foi também o caso em que cumprir a regra custava trinta minutos, porque o que faltava era teste do que eu
mesmo tinha acabado de tocar. É exatamente por isso que ela deve ser bloqueio.

A lição aprendida

Documentação é para explicar o porquê. Ferramenta é para garantir o quê. Documento explica bem e garante
mal. Quando eu escrevo uma regra num documento, o que estou realmente fazendo é apostar na memória coletiva do
time. E essa aposta perde no longo prazo, sempre.

A melhor mensagem de erro é a que chega no momento certo. A mesma frase, lida num documento em janeiro,
não impede nada. Impressa pela ferramenta no segundo em que você tenta fazer a coisa errada, impede tudo.

Guardrail é gentileza, não desconfiança. Ele não existe porque as pessoas são descuidadas. Existe porque
ninguém deveria precisar carregar na cabeça o motivo de cada decisão tomada há três meses por outra pessoa.

Terceiro de três textos sobre migrar um design system em produção sem parar a entrega. Os outros são sobre um
botão que quase desapareceu ao instalar uma biblioteca de CSS, e sobre conviver com duas identidades visuais
ao mesmo tempo.

Duas identidades visuais no mesmo sistema, e a troca que custou quatro linhas

Guilherme Marucchi — Tue, 08 Sep 2026 14:10:37 +0000

No meio de uma migração de design system, a marca mudou.

Não era o plano. O plano era trocar a base técnica dos componentes. O antigo saindo tela a tela, o novo
entrando no lugar. Aí veio a informação de que a identidade visual também ia evoluir: cor primária diferente,
neutros diferentes, tipografia diferente.

Duas mudanças grandes ao mesmo tempo, num sistema com mais de 450 arquivos de estilo e mais de cem telas, sem
poder parar a entrega de produto.

Isto é o que fez a segunda mudança custar quatro linhas em vez de uma varredura.

O problema, sem a camada

Num sistema comum, o componente sabe a cor:

o botão primário é laranja
o card tem fundo branco
a borda é cinza claro

Espalhe isso por algumas centenas de componentes e a troca de identidade vira uma varredura: abrir arquivo
por arquivo, achar cada cor, trocar. E sempre escapa alguma. A que fica é a que ninguém vai encontrar até
um usuário reclamar.

O sistema já tinha um passo dado nessa direção: as cores estavam em variáveis CSS, não escritas à mão em cada
lugar. Isso ajuda, mas não resolve. Porque a variável dizia qual cor é, não para que ela serve:

--marca-laranja-puro: #f60;

E o componente consumia isso direto. Se a marca deixasse de ser laranja, o nome mentia. E se você quisesse
laranja em dois papéis diferentes: ação principal e destaque de aviso? Não havia como mudar um sem mudar
o outro.

Duas camadas, e a distinção é tudo

A separação que resolve é entre paleta e papel.

Paleta: o que a cor é. Um dicionário de tintas. Não diz para que serve.

--paleta-marca: #f60;
--paleta-cinza-200: #e5e5e5;

Papel: o que a cor significa. Um dicionário de funções, apontando para o de tintas.

--primary: var(--paleta-marca);
--border: var(--paleta-cinza-200);

Os componentes consomem só a segunda camada. Nenhum componente sabe qual cor ele está usando; ele sabe
que está pintando uma ação principal.

Parece burocracia até você precisar trocar a identidade. Aí a troca acontece no lado direito de uma linha, e
todos os componentes acompanham. Inclusive os que ainda não foram escritos.

O truque: construir a camada antes de as cores existirem

Aqui está a parte que eu não teria pensado se não fosse a pressão de não ficar parado.

Quando montamos a estrutura, o time de design ainda não tinha entregado a identidade nova. A tentação era
esperar. Em vez disso, declaramos a camada de papéis inteira apontando para as cores antigas:

--primary: var(--paleta-antiga-marca);
--background: var(--paleta-antiga-fundo);

Provisório de propósito. E não é rodeio. Tem duas razões concretas.

Primeira: alguma coisa precisa estar lá. Variável sem valor não renderiza nada, e o catálogo de
componentes que adotamos vem com uma paleta padrão própria. Sem sobrescrever, o sistema inteiro renderizaria
na cara genérica da biblioteca. Nem a identidade antiga, nem a nova.

Segunda, e é a que importa: com as cores antigas, dá para isolar a variável. Montamos uma bancada com um
componente antigo e um novo lado a lado. Se os dois aparecem na mesma cor, a corrente inteira funciona:
token, mapeamento, geração de CSS, pixel na tela. Se aparecem diferentes, alguma coisa quebrou no meio. Com
cores diferentes nos dois lados, não dá para saber se a diferença é bug ou é só a cor.

As cores antigas viraram sinal de teste, não escolha estética.

Quando o design entregou a identidade nova, a implementação foi trocar o lado direito das declarações. A
estrutura já estava provada.

Os dois cenários que a camada torna possíveis

Com paleta e papel separados, existem duas trocas diferentes e a diferença entre elas é o que permite
migrar sem quebrar nada.

Trocar a paleta muda os dois mundos juntos. O componente antigo lê a paleta direto; o novo lê o papel, que
aponta para a paleta. Mudou a tinta, mudou tudo.

Trocar o papel muda só o mundo novo. O componente antigo continua lendo a paleta antiga, intocado.

O segundo é o que a coexistência precisa: a identidade nova entra nos componentes novos enquanto os antigos
seguem como estão. As duas gerações convivem, cada uma lendo a sua camada.

Onde o modelo cedeu

Isso funcionou enquanto a migração só acrescentava. Tela nova nascia lendo o papel, tela antiga seguia na
paleta, e as duas não se cruzavam.

Parou de valer no dia em que telas que já existiam tiveram que vestir a pele nova. Consolidamos cinco telas de
área financeira numa página com abas, depois quatro de outra área. Não eram componentes novos: eram os mesmos
de sempre, precisando de fundo e borda diferentes.

Reescrever cada um na estrutura nova custaria semanas e não era o que estava sendo pedido. Então fizemos o que
o modelo mandava não fazer: nove arquivos de estilo antigos passaram a ler a camada de papel.

/* dentro de um componente antigo */
body.menu-v2 & {
  background: var(--card);
  border: 1px solid var(--sidebar-border);
}

Com isso, "trocar o papel muda só o mundo novo" deixou de ser verdade. Mexer em --card hoje afeta os dois
lados.

O que segurou a coexistência foi o portão mudar de natureza. Antes ele era implícito, dado pela
arquitetura: você estava protegido porque lia outra camada. Agora é explícito, numa classe no body que só
existe quando a flag do menu novo está ligada. Com a flag desligada, aquelas nove regras não casam com nada e
o componente antigo renderiza exatamente como antes.

Trocamos garantia estrutural por garantia condicional. É pior de auditar e melhor de entregar. E essa é a
troca honesta: o modelo puro exigiria reescrever o componente antes de poder mudar a aparência dele, e isso
não caberia no cronograma.

Um detalhe de CSS que me pegou

Montei uma demonstração com botões para alternar entre os cenários e mostrar isso ao vivo. Aplicei as
variáveis numa <div> que envolvia os componentes.

Funcionou para um lado e não para o outro. Trocar o papel mudava o componente novo; trocar a paleta não
mudava nada no novo.

O motivo é uma sutileza que vale conhecer: a substituição do var() acontece no elemento onde a
propriedade é declarada, não onde ela é usada.

O papel estava declarado no :root, apontando para a paleta:

:root {
  --paleta-marca: #f60;
  --primary: var(--paleta-marca);
}

Nesse momento, ali no :root, o --primary já foi resolvido para #f60. O que desce por herança para os
elementos filhos é a cor pronta, não a fórmula. Sobrescrever --paleta-marca numa <div> lá embaixo não
tinha como voltar atrás e recalcular.

Em produção isso não acontece, porque as duas camadas são declaradas no mesmo :root. Trocar a paleta ali
propaga de verdade. O erro era só da bancada, e a correção foi aplicar as variáveis no próprio :root, que
é o que espelha o comportamento real.

O nome do token é uma decisão de longo prazo

Uma armadilha que aparece exatamente nesse momento: a tentação de marcar a geração no nome.

--primary-v2
--marca-nova
--cor-primaria-2026

Parece organizado. É uma bomba-relógio: em dezoito meses a "v2" é a única que existe, e o nome mente para
todo mundo que ler. Aí alguém cria a v3.

A regra que sobrevive: nome de tinta descreve a cor; nome de papel descreve a função. Nenhum dos dois
carrega versão.

Onde a versão aparece é no portão, e ali ela é bem-vinda: existe uma classe menu-v2 no body, com o número
no nome de propósito. A diferença é o tempo de vida. Token é vocabulário permanente, e quando o nome mente
a dívida fica para sempre. A classe é temporária por construção: quando a migração terminar, ela sai e
leva o número junto.

O que não deu certo

Duas coisas, para não parecer que foi tranquilo.

A tipografia não cabe no mesmo modelo. Cor é fácil de escopar: o componente novo lê o papel novo, o antigo
lê a paleta antiga, e eles não se falam. Fonte é herdada. O texto que não declara família herda do body, e
trocar o padrão do body mudaria a fonte de todo o texto herdado de uma vez. Sem lista, sem teste que
pegue.

A saída foi escopar a fonte nova aos componentes novos por um atributo que só eles têm, e deixar a inversão
para o fim da migração, quando o antigo não existir mais. Funciona, mas é remendo com data marcada, não
elegância.

O contraste ficou abaixo do mínimo. Medi os pares de cor da identidade nova contra o critério de
acessibilidade: nenhum atinge o mínimo para texto pequeno, que é o tamanho do rótulo padrão dos botões. Levei
ao design com os números; a decisão foi manter.

Registro os dois porque é o que separa relato de propaganda. A camada de tokens resolveu o problema para o
qual foi feita. Não resolveu tudo.

Segundo de três textos sobre migrar um design system em produção sem parar a entrega. O primeiro é sobre um
botão que quase desapareceu ao instalar uma biblioteca de CSS. O próximo é sobre por que quase toda regra de
migração que vive num documento acaba sendo violada, e o que fazer a respeito.

# Instalar uma biblioteca de CSS quase apagou um botão do sistema

Guilherme Marucchi — Thu, 20 Aug 2026 11:52:58 +0000

Eu tinha acabado de instalar o Tailwind em um sistema que roda sobre styled-components há anos. Build passou. Cinco mil e quinhentos testes, verdes. Novecentos e sessenta snapshots, intactos.

Podia ter seguido em frente. Mas abri o CSS que o build tinha gerado só para ver como estava.

Havia 41 classes utilitárias ali dentro. E eu não tinha escrito nenhuma classe do Tailwind no projeto.

O que estava acontecendo

O Tailwind não sabe quais classes você vai usar. Ele descobre lendo os seus arquivos e procurando algo que
pareça nome de classe. É por isso que ele é rápido: em vez de gerar milhares de regras e você jogar fora o
que não usa, ele gera só o que encontrou.

O detalhe é que essa leitura é textual. Ele não entende TypeScript, não sabe o que é JSX, não distingue
uma string de um comentário. Ele varre o arquivo procurando padrões que se pareçam com classes.

E num projeto com styled-components, os arquivos de estilo são cheios de texto assim:

export const Wrapper = styled.div`
  display: flex;
  position: absolute;
  visibility: collapse;
`

Para o Tailwind, aquele flex é um candidato. absolute também. E collapse também.

Eram esses os 41.

O problema não era o desperdício

Oito quilobytes de CSS que ninguém usa é chato, não é grave. O problema apareceu quando fui cruzar as classes
geradas com as que o sistema já usava de verdade.

Doze colidiam. E uma delas era esta:

<button className="collapse" onClick={() => setIsOpen(!isOpen)}>

Um botão real, numa tela real, com uma classe chamada collapse porque ele colapsa um painel.

O Tailwind tinha gerado:

.collapse { visibility: collapse }

Em elemento que não é tabela, visibility: collapse se comporta como hidden.

Aquele botão desapareceria da tela.

"Mas o CSS antigo não venceria?"

Foi a primeira coisa que eu pensei. As duas regras miram o mesmo elemento, e o styled-components injeta o CSS
dele fora das cascade layers. O que, pela especificação, sempre ganha de quem está dentro de uma layer, como
o Tailwind está.

Só que a cascata não escolhe um vencedor por regra. Ela escolhe por propriedade.

A regra do sistema era assim:

button.collapse {
  appearance: none;
  border: none;
  outline: none;
  cursor: pointer;
  background-color: transparent;
}

Cinco propriedades. Nenhuma delas é visibility.

Sem disputa, não há vencedor: as duas regras simplesmente se somam. O visibility: collapse do Tailwind
entrava sem encontrar resistência.

Essa é a parte que eu tinha entendido errado, e é a que mais vale levar daqui: layer e especificidade só
resolvem conflito na mesma propriedade. Onde uma regra declara algo que a outra não declara, as duas
valem.

Por que ninguém teria percebido

É aqui que a coisa fica desconfortável.

O build passa. É CSS válido
Os testes passam. Eles verificam comportamento e marcação, não estilo computado
Os snapshots passam. A marcação não muda — o botão continua no DOM, com a mesma classe
A revisão de código não pega. O diff mostra um arquivo de configuração de três linhas

Não existe ferramenta no caminho normal que veja isso. O único jeito de encontrar era fazer o que eu fiz por
acaso: abrir o CSS gerado e olhar.

E o mesmo mecanismo tinha produzido .container { width: 100% }, que se aplicaria a 22 elementos espalhados
por dez arquivos.

A correção, e o que ela revelou

O Tailwind aceita desligar a varredura automática e declarar explicitamente onde ele pode procurar:

@import 'tailwindcss/utilities.css' layer(utilities) source(none);

@source '../components';

Segundo build: zero classes geradas a partir do código antigo. Zero colisões.

Mas o que me fez gostar dessa correção não foi ela resolver o bug. Foi o efeito colateral.

O projeto está numa migração gradual: um design system novo entrando enquanto o antigo sai, tela por tela. A
regra número um dessa migração é que os dois não se misturem no mesmo arquivo — os dois geram classes com a
mesma especificidade, e quem vence passa a depender de detalhes que ninguém controla.

Essa regra estava num documento. Documento que alguém precisa ler, lembrar e aplicar.

Com o @source restrito, ela deixou de precisar disso: classe do padrão novo escrita dentro de um arquivo
do padrão antigo simplesmente não é gerada. O componente aparece sem estilo, a pessoa percebe na hora, e
ninguém precisa ter lido nada.

A regra saiu do documento e virou comportamento de build.

Não foi sorte

Sei disso porque a mesma prática pegou um segundo problema, no mesmo dia.

Os componentes que vêm do catálogo trazem classes de tema escuro de fábrica — coisas como
dark:bg-destructive/60. Vieram dez delas junto com os dois primeiros componentes.

No comportamento padrão da ferramenta, o prefixo dark: compila para:

@media (prefers-color-scheme: dark) { ... }

Ou seja: essas dez regras passariam a valer sozinhas para todo usuário com o sistema operacional em tema
escuro. Num sistema que não tem tema escuro nenhum.

Uma parcela enorme de gente usa o sistema em modo escuro. Todos eles veriam botões com tons ligeiramente
diferentes, bordas trocadas e hovers estranhos.

A correção é uma linha, que prende o prefixo a uma classe em vez de ao sistema:

@custom-variant dark (&:is(.dark *));

Como essa classe não existe no projeto, as dez regras ficam inertes. E no dia em que o tema escuro entrar,
todas passam a valer de uma vez.

O que eu levo disso

Build verde não é verificação, é ausência de erro de compilação. São coisas diferentes, e a distância
entre elas é exatamente onde mora a classe de bug que ninguém encontra.

Ler a saída da ferramenta é barato. Os dois problemas apareceram em minutos, porque eu olhei o CSS
gerado em vez de confiar no build. O custo de olhar é sempre menor que o custo de descobrir depois — e
"depois" aqui significaria um chamado de usuário dizendo que não consegue mais abrir uma tela.

A melhor correção é a que transforma a regra em comportamento. Toda migração produz um monte de "não faça
X". Cada uma dessas regras depende de alguém lembrar, e memória de time não escala. Quando dá para fazer a
ferramenta recusar, a regra para de ser combinada e passa a ser verdade.

Este é o primeiro de três textos sobre migrar um design system num sistema em produção sem parar a entrega.
O próximo é sobre conviver com duas identidades visuais ao mesmo tempo, e como uma camada de tokens
transformou uma troca de marca em quatro linhas alteradas.

# Feature Flags em React/Next.js: Guia Completo com ConfigCat e Context API

Guilherme Marucchi — Tue, 19 May 2026 10:52:39 +0000

Introdução

Se você já passou por alguma dessas situações, este artigo é pra você:

Precisou fazer rollback de um deploy e isso bloqueou toda a equipe de subir código
Teve conflitos intermináveis na branch develop porque várias features estavam sendo desenvolvidas ao mesmo tempo
Quis testar uma funcionalidade em produção apenas com um grupo específico de usuários antes de liberar pra todos
Descobriu um bug crítico em produção e precisou esperar um novo deploy pra resolver

Feature Flags (ou Feature Toggles) resolvem todos esses problemas. Neste guia, vou mostrar passo a passo como implementei feature flags em uma aplicação Next.js usando ConfigCat como serviço externo e React Context API como camada de abstração — uma arquitetura desacoplada, escalável e pronta pra produção.

O que são Feature Flags?

Feature Flags são interruptores que permitem ligar e desligar funcionalidades da sua aplicação sem precisar fazer deploy. O código da feature já está em produção, mas só é executado quando a flag está ativa.

Pense assim: é como ter um painel de controle onde você decide, em tempo real, o que cada usuário vê na aplicação.

O que você ganha com isso?

✅ Deploy contínuo sem medo — suba o código com a feature desligada
✅ Teste em produção com segurança — ligue apenas pro seu usuário
✅ Kill switch instantâneo — desligou a flag, a feature some em segundos
✅ Rollout gradual — libere pra 10%, depois 50%, depois 100%
✅ Sem conflitos de branch — todo mundo sobe pra main/develop, a flag controla quem vê o quê

Por que ConfigCat?

Existem várias ferramentas de feature flags no mercado (LaunchDarkly, Unleash, Split.io). Escolhi o ConfigCat por:

Interface intuitiva — dashboard simples e direto ao ponto
Suporte nativo a React — SDK com Provider e hooks prontos
Targeting avançado — controle por usuário, atributos customizados, porcentagem
Plano gratuito generoso — suficiente pra começar
Polling automático — atualiza os valores das flags periodicamente sem você precisar fazer nada

Arquitetura da Solução

A decisão mais importante da implementação: não acoplar a aplicação ao ConfigCat.

Se amanhã você precisar trocar de ferramenta, só altera o Provider. Nenhum componente da aplicação sabe que o ConfigCat existe.

Estrutura de pastas

src/
├── utils/consts/
│   └── featureFlags.ts          # Constantes das flags + SDK keys
├── providers/feature-flags/
│   └── featureFlagsContext.tsx   # Context + Provider + sincronização
└── pages/
    └── _app.tsx                 # Provider na árvore de componentes

Fluxo da arquitetura

ConfigCat (serviço externo)
    ↓ polling a cada N segundos
ConfigCatReactProvider (engine — busca, cache, polling)
    ↓
ConfigCatSync (sincroniza user + busca flags boolean e string + escuta mudanças)
    ↓ armazena no useState
FeatureFlagsContext.Provider (Context próprio do projeto)
    ↓ expõe via useContext
Componentes (consomem com getFlag ou getStringFlag, não sabem que ConfigCat existe)

Implementação Passo a Passo

1. Instalação

npm install configcat-react

2. Constantes tipadas

Primeiro, crie as constantes das flags e as SDK keys. A implementação suporta dois tipos de flags: boolean (liga/desliga) e string (valor variável, útil para A/B testing e conteúdo dinâmico).

// src/utils/consts/featureFlags.ts

export const featureFlags = {
  SHOW_DASHBOARD: 'showDashboard',
  ENABLE_NEW_CHECKOUT: 'enableNewCheckout'
} as const

export const stringFeatureFlags = {
  ACTIVE_PROMOTION: 'activePromotion'
} as const

export type FeatureFlagKey = (typeof featureFlags)[keyof typeof featureFlags]
export type StringFeatureFlagKey = (typeof stringFeatureFlags)[keyof typeof stringFeatureFlags]

export const configCatSdkKeys = {
  TEST: '<your-configcat-sdk-key-test>',
  PRODUCTION: '<your-configcat-sdk-key-production>'
} as const

Por que tipar? O TypeScript garante que você não vai digitar o nome errado de uma flag. Se tentar usar uma string que não existe no objeto, o compilador avisa.

Por que dois objetos separados? Flags boolean e string têm contratos de retorno diferentes — { isEnabled, isLoading } vs { value, isLoading }. Separar os objetos permite tipar cada método (getFlag e getStringFlag) de forma precisa, sem abrir mão de type safety.

Por que as SDK keys estão no código e não em .env? As SDK keys do ConfigCat são públicas por design — elas só permitem leitura das flags, não alteração. Colocá-las no código junto com uma função de detecção de ambiente (como veremos a seguir) elimina a necessidade de gerenciar arquivos .env por ambiente.

Agora exporte as constantes no barrel do projeto pra que fiquem acessíveis:

// src/utils/consts/index.ts
import { featureFlags, stringFeatureFlags, configCatSdkKeys } from './featureFlags'

const Consts = {
  // ... outras constantes do projeto
  featureFlags,
  stringFeatureFlags,
  configCatSdkKeys
}

export default Consts

E exporte os tipos:

// src/utils/index.ts
export type { FeatureFlagKey, StringFeatureFlagKey } from './consts/featureFlags'

3. Detecção de ambiente

Em vez de depender de variáveis de ambiente (.env.local, .env.production), use uma função que detecta o ambiente em runtime:

// src/lib/getIsProduction.ts

const hostsProduction = [
  'app.meudominio.com.br',
  'app-stg.meudominio.com.br'
]

const getIsProduction = () =>
  process.env.BUILD_ENV === 'production' ||
  (typeof window !== 'undefined' &&
    hostsProduction.includes(window.location.host))

export default getIsProduction

Isso permite que o Provider escolha a SDK key correta automaticamente, sem depender de arquivos .env.

4. O Provider — coração da implementação

Aqui é onde tudo acontece. O Provider tem 3 responsabilidades:

Inicializar o ConfigCat com a SDK key correta
Sincronizar os dados do usuário logado com o ConfigCat (pra targeting)
Buscar todas as flags e expor via Context próprio do projeto

// src/providers/feature-flags/featureFlagsContext.tsx
'use client'

import {
  createContext,
  useCallback,
  useContext,
  useEffect,
  useMemo,
  useState
} from 'react'

import {
  ConfigCatProvider as ConfigCatReactProvider,
  useConfigCatClient,
  User
} from 'configcat-react'

import { getIsProduction } from 'lib'

import { Consts, FeatureFlagKey, StringFeatureFlagKey } from 'utils'

import { UserContext } from 'providers/user/userContext'

type FlagState = {
  value: boolean | string
  loading: boolean
}

type FeatureFlagsContextProps = {
  flags: Record<string, FlagState>
  getFlag: (key: FeatureFlagKey) => { isEnabled: boolean; isLoading: boolean }
  getStringFlag: (key: StringFeatureFlagKey) => { value: string; isLoading: boolean }
}

const defaultFlagState = { isEnabled: false, isLoading: true }
const defaultStringFlagState = { value: '', isLoading: true }

export const FeatureFlagsContext = createContext<FeatureFlagsContextProps>({
  flags: {},
  getFlag: () => defaultFlagState,
  getStringFlag: () => defaultStringFlagState
})

Detalhe importante: o defaultFlagState retorna isEnabled: false e isLoading: true. O defaultStringFlagState retorna value: '' e isLoading: true. Enquanto as flags não carregaram, nenhuma feature controlada por flag aparece — comportamento seguro por padrão.

ConfigCatSync — o componente que faz a mágica

const ConfigCatSync = ({ children }: { children: React.ReactNode }) => {
  const { user } = useContext(UserContext)
  const client = useConfigCatClient()
  const [flags, setFlags] = useState<Record<string, FlagState>>({})

  // Sincroniza dados do usuário logado com o ConfigCat
  useEffect(() => {
    if (!client) return

    if (user) {
      const configCatUser = new User(user.email, user.email, undefined, {
        role: user.role || '',
        plan: user.plan || '',
        is_admin: user.isAdmin ? '1' : '0'
        // Adicione quantos atributos precisar pro targeting
      })

      client.setDefaultUser(configCatUser)
    } else {
      client.clearDefaultUser()
    }
  }, [client, user])

  // Busca todas as flags e escuta mudanças
  useEffect(() => {
    if (!client) return

    const fetchAllFlags = async () => {
      const booleanKeys = Object.values(Consts.featureFlags)
      const stringKeys = Object.values(Consts.stringFeatureFlags)

      const booleanEntries = await Promise.all(
        booleanKeys.map(async (key) => {
          const value = await client.getValueAsync(key, false)
          return [key, { value: Boolean(value), loading: false }] as const
        })
      )

      const stringEntries = await Promise.all(
        stringKeys.map(async (key) => {
          const value = await client.getValueAsync(key, '')
          return [key, { value: String(value), loading: false }] as const
        })
      )

      setFlags(Object.fromEntries([...booleanEntries, ...stringEntries]))
    }

    fetchAllFlags()

    const handler = () => {
      fetchAllFlags()
    }

    client.on('configChanged', handler)

    return () => {
      client.off('configChanged', handler)
    }
  }, [client, user])

  const getFlag = useCallback(
    (key: FeatureFlagKey) => {
      const flag = flags[key]
      if (!flag) return defaultFlagState
      return { isEnabled: Boolean(flag.value), isLoading: flag.loading }
    },
    [flags]
  )

  const getStringFlag = useCallback(
    (key: StringFeatureFlagKey) => {
      const flag = flags[key]
      if (!flag) return defaultStringFlagState
      return { value: String(flag.value), isLoading: flag.loading }
    },
    [flags]
  )

  const contextValue = useMemo(
    () => ({ flags, getFlag, getStringFlag }),
    [flags, getFlag, getStringFlag]
  )

  return (
    <FeatureFlagsContext.Provider value={contextValue}>
      {children}
    </FeatureFlagsContext.Provider>
  )
}

O que está acontecendo aqui:

O primeiro useEffect sincroniza os dados do usuário logado com o ConfigCat. Isso permite targeting por atributos (ex: "mostrar só pra admins")
O segundo useEffect busca todas as flags de uma vez — boolean e string separadamente — e armazena no useState. Note que user faz parte das dependências: quando o usuário troca (ex: login/logout), as flags são rebuscadas automaticamente com o novo contexto de targeting
O client.on('configChanged', handler) escuta mudanças: quando o ConfigCat detecta uma atualização via polling, o handler rebusca todas as flags automaticamente, sem refresh da página
O useMemo no contextValue evita re-renders desnecessários nos componentes consumidores

O Provider principal

type FeatureFlagsProviderProps = {
  children: React.ReactNode
}

const FeatureFlagsProvider = ({ children }: FeatureFlagsProviderProps) => {
  const sdkKey = getIsProduction()
    ? Consts.configCatSdkKeys.PRODUCTION
    : Consts.configCatSdkKeys.TEST

  return (
    <ConfigCatReactProvider
      sdkKey={sdkKey}
      options={{ pollIntervalSeconds: 3600 }}
    >
      <ConfigCatSync>{children}</ConfigCatSync>
    </ConfigCatReactProvider>
  )
}

export default FeatureFlagsProvider

Sobre o pollIntervalSeconds: o padrão do ConfigCat é 60 segundos. Usamos 3600 (1 hora) porque, na maioria dos casos, flags não precisam propagar imediatamente — e intervalos curtos consomem quota do plano desnecessariamente. Se o seu cenário exigir propagação mais rápida (ex: kill switch urgente), reduzir para 60 ou 120 é razoável. O importante é calibrar conforme a necessidade real, não usar o menor valor possível.

5. Adicionar na árvore de componentes

// src/pages/_app.tsx
import FeatureFlagsProvider from 'providers/feature-flags/featureFlagsContext'

function App({ Component, pageProps }) {
  return (
    <UserProvider>
      <FeatureFlagsProvider>
        <Component {...pageProps} />
      </FeatureFlagsProvider>
    </UserProvider>
  )
}

Ordem importa: o FeatureFlagsProvider precisa estar dentro do UserProvider, porque o ConfigCatSync consome o UserContext pra sincronizar os dados do usuário.

Configurando no Dashboard do ConfigCat

Criando uma flag boolean

Acesse o dashboard do ConfigCat
Crie uma feature flag do tipo On/Off Toggle com o nome exato que você definiu na constante (ex: showDashboard)
Configure o valor padrão como OFF

Criando uma flag string

No dashboard, crie uma feature flag do tipo Text
Use o nome exato da constante em stringFeatureFlags (ex: activePromotion)
Configure o valor padrão como string vazia ou um valor seguro

Configurando ambientes

O ConfigCat separa ambientes por SDK key. Cada ambiente tem sua própria key:

Test/Development — use a key de teste
Production — use a key de produção

Isso significa que você pode ter a flag ON em teste e OFF em produção ao mesmo tempo.

Consumindo nos Componentes

Exemplo 1: Controlar visibilidade de um item no menu

import { useContext, useMemo } from 'react'

import { Consts } from 'utils'

import { FeatureFlagsContext } from 'providers/feature-flags/featureFlagsContext'

const Menu = ({ loggedUser }) => {
  const { getFlag } = useContext(FeatureFlagsContext)
  const { isEnabled: showDashboard } = getFlag(
    Consts.featureFlags.SHOW_DASHBOARD
  )

  const menuItems = useMemo(() => {
    const base = [
      { label: 'Parcelas', url: '/app/parcelas' },
      { label: 'Recibos', url: '/app/recibos' }
    ]

    if (loggedUser.isAdmin && showDashboard) {
      base.unshift({ label: 'Dashboard', url: '/app/dashboard' })
    }

    return base
  }, [loggedUser, showDashboard])

  return (
    <nav>
      <ul>
        {menuItems.map((item) => (
          <li key={item.url}>
            <a href={item.url}>{item.label}</a>
          </li>
        ))}
      </ul>
    </nav>
  )
}

Perceba: o componente importa FeatureFlagsContext — não sabe nada sobre ConfigCat. Se amanhã trocar de ferramenta, este componente não muda.

Exemplo 2: Proteger uma página inteira com redirect

import { useContext, useEffect } from 'react'

import { useRouter } from 'next/router'

import { Consts } from 'utils'

import { FeatureFlagsContext } from 'providers/feature-flags/featureFlagsContext'

const DashboardPage = () => {
  const { push } = useRouter()
  const { getFlag } = useContext(FeatureFlagsContext)
  const { isEnabled: showDashboard, isLoading } = getFlag(
    Consts.featureFlags.SHOW_DASHBOARD
  )

  useEffect(() => {
    if (!isLoading && !showDashboard) {
      push('/app')
    }
  }, [isLoading, showDashboard, push])

  if (isLoading) return null

  return <div>Conteúdo do Dashboard</div>
}

Por que checar isLoading? Sem essa checagem, o componente faria redirect imediatamente no primeiro render (porque isEnabled começa como false enquanto as flags carregam). O isLoading garante que o redirect só acontece depois que o ConfigCat respondeu.

Exemplo 3: Exibição condicional de um componente

import { useContext } from 'react'

import { Consts } from 'utils'

import { FeatureFlagsContext } from 'providers/feature-flags/featureFlagsContext'

const HomePage = () => {
  const { getFlag } = useContext(FeatureFlagsContext)
  const { isEnabled: enableNewCheckout } = getFlag(
    Consts.featureFlags.ENABLE_NEW_CHECKOUT
  )

  return (
    <div>
      <h1>Bem-vindo</h1>
      {enableNewCheckout ? <NewCheckout /> : <LegacyCheckout />}
    </div>
  )
}

Exemplo 4: Flag string para conteúdo dinâmico

Flags string são ideais quando você precisa não só de ligar/desligar, mas de controlar qual variante exibir — A/B testing, banners sazonais, temas, e afins.

import { useContext } from 'react'

import { Consts } from 'utils'

import { FeatureFlagsContext } from 'providers/feature-flags/featureFlagsContext'

const PromoBanner = () => {
  const { getStringFlag } = useContext(FeatureFlagsContext)
  const { value: activePromotion, isLoading } = getStringFlag(
    Consts.stringFeatureFlags.ACTIVE_PROMOTION
  )

  if (isLoading || !activePromotion) return null

  return <Banner type={activePromotion} />
}

No dashboard do ConfigCat, você configura o valor da flag como 'black-friday', 'cyber-monday' ou string vazia (desligado). Zero deploy pra trocar a campanha ativa.

User Targeting — A Mágica de Verdade

A parte mais poderosa das feature flags é o targeting. Com os dados do usuário sincronizados no ConfigCatSync, você pode criar regras no dashboard como:

Targeting por email (testar com seu próprio usuário)

IF User.email IS ONE OF ["dev@empresa.com"]
THEN serve: ON
To everyone else: OFF

Targeting por atributo (liberar pra admins)

IF User.is_admin EQUALS "1"
THEN serve: ON
To everyone else: OFF

Rollout por porcentagem

10% dos usuários: ON
90% dos usuários: OFF

Isso permite um rollout gradual: comece com 10%, monitore, aumente pra 50%, e finalmente 100%.

Testes

Mock do ConfigCat para Jest

Como o ConfigCat é uma dependência externa, precisamos mocká-lo nos testes. O mock deve cobrir todos os símbolos usados pelo featureFlagsContext.tsx:

// __mocks__/configcat-react.js
module.exports = {
  ConfigCatProvider: ({ children }) => children,
  useConfigCatClient: () => ({
    getValueAsync: (key, defaultValue) => Promise.resolve(defaultValue),
    setDefaultUser: () => {},
    clearDefaultUser: () => {},
    on: () => {},
    off: () => {}
  }),
  User: class User {
    constructor() {}
  }
}

Configurar no jest.config.js

module.exports = {
  moduleNameMapper: {
    '^configcat-react$': '<rootDir>/__mocks__/configcat-react.js'
  }
}

Mock do Context nos testes de componentes

Na prática, a maioria dos testes de componentes não precisa exercitar o Provider inteiro — basta mockar o Context diretamente. Inclua getStringFlag junto com getFlag:

jest.mock('providers/feature-flags/featureFlagsContext', () => ({
  FeatureFlagsContext: {
    _currentValue: {
      flags: {},
      getFlag: () => ({ isEnabled: true, isLoading: false }),
      getStringFlag: () => ({ value: 'default', isLoading: false })
    }
  }
}))

Isso faz com que todas as flags boolean retornem true e as string retornem 'default' nos testes — comportamento padrão que geralmente você quer ao testar o caminho feliz.

Para testar o cenário com flag desligada:

jest.mock('providers/feature-flags/featureFlagsContext', () => ({
  FeatureFlagsContext: {
    _currentValue: {
      flags: {},
      getFlag: () => ({ isEnabled: false, isLoading: false }),
      getStringFlag: () => ({ value: '', isLoading: false })
    }
  }
}))

Para testar o estado de carregamento:

jest.mock('providers/feature-flags/featureFlagsContext', () => ({
  FeatureFlagsContext: {
    _currentValue: {
      flags: {},
      getFlag: () => ({ isEnabled: false, isLoading: true }),
      getStringFlag: () => ({ value: '', isLoading: true })
    }
  }
}))

Casos de Uso Reais

1. Deploy Seguro

Você desenvolveu uma feature nova. Em vez de esperar pra fazer merge só quando estiver 100% pronta:

Suba o código com a flag OFF
No dashboard, ligue apenas pro seu email
Teste em produção com dados reais
Quando estiver pronto, ligue pra todos

Zero conflito de branch. Zero rollback.

2. Kill Switch

Feature causando problemas em produção?

Abra o dashboard do ConfigCat
Desligue a flag
Em até uma hora (ou o intervalo de polling configurado), a feature desaparece

Sem deploy. Sem rollback. Sem estresse.

3. Apresentação para Stakeholders

Quer mostrar uma feature nova só pros diretores antes de liberar?

Crie uma regra de targeting com os emails dos diretores
Ligue a flag
Eles veem a feature, o resto dos usuários não

4. Rollout Gradual

Feature nova que pode impactar performance?

Dia 1: 10% dos usuários
Dia 3: 50% dos usuários
Dia 5: 100% dos usuários

Se em qualquer momento algo der errado, volte pra 0%.

5. Campanha ou Conteúdo Dinâmico (flag string)

Você tem um banner que muda conforme a campanha ativa. Em vez de fazer deploy a cada troca:

Crie uma flag string activePromotion no ConfigCat
Configure o valor como 'black-friday' quando a campanha começa
Mude para '' (vazio) quando terminar

O componente reage automaticamente quando o polling detecta a mudança — sem deploy, sem redeploy, sem acionar o time de infra.

Boas Práticas

1. Nomenclatura consistente

Use camelCase nas flags (padrão do ConfigCat) e UPPER_SNAKE_CASE nas constantes:

// ✅ Bom — claro e descritivo
featureFlags = {
  SHOW_DASHBOARD: 'showDashboard',
  ENABLE_NEW_CHECKOUT: 'enableNewCheckout'
}

stringFeatureFlags = {
  ACTIVE_PROMOTION: 'activePromotion'
}

// ❌ Ruim — ambíguo
featureFlags = {
  DASH: 'dash',
  CHECKOUT: 'checkout'
}

2. Escolha o tipo certo de flag

Use boolean quando...	Use string quando...
Ligar/desligar uma feature	Controlar qual variante exibir
Proteger uma rota	Selecionar um tema ou layout
Feature em rollout gradual	A/B testing com múltiplas variantes
Kill switch de emergência	Conteúdo dinâmico (banners, campanhas)

3. Limpeza de flags antigas

Flags são código temporário. Quando a feature estiver 100% liberada e estável:

Remova a flag do código (o if com getFlag ou o componente com getStringFlag)
Remova a constante do featureFlags ou stringFeatureFlags
Delete a flag do dashboard do ConfigCat

Flag esquecida é dívida técnica.

4. Comportamento seguro por padrão

O defaultFlagState retorna isEnabled: false e o defaultStringFlagState retorna value: ''. Se o ConfigCat estiver fora do ar ou demorar pra responder, nenhuma feature nova aparece — o usuário vê a versão estável da aplicação.

5. Use `isLoading` em páginas protegidas

Sempre cheque isLoading antes de tomar decisões como redirect:

// ✅ Bom — espera carregar antes de decidir
const { isEnabled, isLoading } = getFlag(Consts.featureFlags.SHOW_DASHBOARD)

useEffect(() => {
  if (!isLoading && !isEnabled) {
    push('/app')
  }
}, [isLoading, isEnabled, push])

// ❌ Ruim — redireciona antes de saber o valor real
const { isEnabled } = getFlag(Consts.featureFlags.SHOW_DASHBOARD)

useEffect(() => {
  if (!isEnabled) {
    push('/app') // Vai redirecionar no primeiro render!
  }
}, [isEnabled, push])

Vantagens da Arquitetura

Desacoplamento total

// Componentes não conhecem ConfigCat
import { FeatureFlagsContext } from 'providers/feature-flags/featureFlagsContext'

const { getFlag, getStringFlag } = useContext(FeatureFlagsContext)

Fácil migração

Para trocar ConfigCat por outra ferramenta (ex: LaunchDarkly), você altera apenas o ConfigCatSync e o FeatureFlagsProvider. Os componentes continuam usando useContext(FeatureFlagsContext) + getFlag/getStringFlag — não mudam nada.

Estado centralizado

Todas as flags são buscadas uma vez e compartilhadas via Context. Se 10 componentes usam a mesma flag, o ConfigCat é consultado uma vez só — não 10 vezes.

Reatividade automática

O listener configChanged garante que quando uma flag muda no dashboard, todos os componentes que a consomem atualizam automaticamente, sem refresh da página. Isso vale tanto para flags boolean quanto string.

Dois tipos de flag, um contrato unificado

O Context expõe getFlag e getStringFlag com contratos claros e tipados. Componentes nunca lidam com any ou precisam fazer cast — o TypeScript guia o uso correto desde o autocompletar.

Conclusão

Feature Flags transformaram a forma como fazemos deploy. Com ConfigCat como engine e React Context API como camada de abstração, conseguimos:

✅ Deploy contínuo sem medo
✅ Testes em produção com segurança
✅ Kill switch instantâneo
✅ Targeting avançado por usuário
✅ Suporte a flags boolean e string
✅ Estado centralizado e reativo
✅ Arquitetura desacoplada — pronta pra trocar de ferramenta
✅ TypeScript garantindo type safety nas flags

O investimento de criar a camada de abstração com Context API vale muito a pena. O código fica limpo, testável e preparado pro futuro.

Indo Além — O que este guia não cobre

O que implementamos aqui é uma base sólida e pronta pra produção. Mas feature flags como conceito têm muito mais profundidade. Se você quiser continuar explorando:

Outros tipos de valor
Além de boolean e string, ferramentas como ConfigCat suportam flags do tipo int, double e até JSON. Isso abre espaço para casos como configurar limites dinâmicos (rate limit, tamanho de paginação, timeout de requisição) ou passar objetos de configuração inteiros sem deploy.

Flags no servidor
A implementação deste artigo é inteiramente client-side. Em aplicações Next.js com uso intenso de SSR ou Server Components, você pode — e muitas vezes deve — avaliar flags no servidor, antes de renderizar a página. Isso evita flashes de conteúdo (o usuário nunca vê o estado "carregando") e permite decisões de roteamento ainda na borda.

Testes com flags em múltiplos estados no CI
Uma flag desligada em produção não significa que o código por trás dela está livre de bugs. Estratégias de CI/CD mais avançadas rodam o pipeline com a flag ligada e desligada, garantindo que ambos os caminhos sejam validados antes do merge.

Gestão do ciclo de vida das flags
Flags acumuladas viram dívida técnica silenciosa. Existem abordagens para rastrear a idade de cada flag, definir uma data de expiração desde a criação, e automatizar alertas quando uma flag passa do prazo esperado — antes que ela vire um if esquecido no código.

Plataformas de experimentação
Feature flags são o passo zero de um experimento. Ferramentas como LaunchDarkly, Split.io e GrowthBook vão além: medem o impacto estatístico de cada variante, calculam significância e ajudam a tomar decisões de produto baseadas em dados — não em intuição.

Cada um desses tópicos rende um artigo próprio. O importante é que a arquitetura que construímos aqui já está preparada para evoluir em qualquer dessas direções — o desacoplamento via Context API garante isso.

Recursos

Escrito por Guilherme Marucchi — Meu LinkedIn