Feature flags explicadas:lance no escuro, ative num botão

Feature flags explicadas: uma feature flag é um interruptor liga/desliga guardado no banco de dados, e não no código: a funcionalidade vai para produção no escuro — publicada, mas invisível — e você a lança depois ligando o interruptor para um cliente beta, para 10% dos usuários ou para todo mundo. Sem novo deploy, sem mudança de código, sem pânico no dia do lançamento.

Para um fundador solo, as flags são a diferença entre o "lançamento" ser um deploy aterrorizante e ser uma decisão tomada tomando um café. Veja como elas funcionam, as quatro formas como você vai realmente usá-las e os erros que fazem o tiro sair pela culatra.

Feature flags explicadas: o que é, de fato, uma feature flag

Sem flags, controlar quem vê uma funcionalidade significa editar código. A gambiarra clássica é assim: "se o e-mail do usuário terminar no domínio do cliente beta, mostre a nova funcionalidade". Cada mudança nessa regra é uma mudança de código, e cada mudança de código é um deploy. A configuração fica espalhada em cinco lugares diferentes, nada tem trilha de auditoria, e quem consegue ligar o interruptor é quem sabe onde a gambiarra está.

Uma feature flag leva essa decisão para os dados. A flag é um interruptor com nome — "new_dashboard: off" — guardado no seu sistema de configurações, ao lado de coisas como fuso horário e tema. O seu código faz uma única pergunta: esta flag está ligada para este usuário? Mude a resposta num painel e o produto muda de comportamento na hora — sem deploy. As flags ficam na mesma hierarquia do resto das suas configurações: um padrão global, que pode ser sobrescrito por organização, que pode ser sobrescrito por usuário.

Publique no escuro, lance num botão

A grande virada de chave mental é que publicar e lançar são dois eventos diferentes, e as flags são o que os separa.

Publicar significa que o seu código chegou ao servidor. Lançar significa que os usuários conseguem ver. Sem flags, os dois são o mesmo momento — é por isso que lançamentos parecem perigosos, e é por isso que fundadores ficam sentados em cima de trabalho pronto por semanas esperando o dia "certo". Com flags, você publica a funcionalidade pela metade, no escuro, dez vezes se quiser. Ela vai junto em cada release, testada em produção, visível só para você. Quando estiver pronta, lançar é apertar um botão — e se fazer deploy ainda te dá medo, esse é o padrão que tira a maior parte do medo.

Isso também muda o seu marketing. Quando lançar não custa nada, você para de apostar tudo num único grande dia e começa a soltar um fluxo de pequenos lançamentos controlados por flags — o motor por trás dos micro-lançamentos.

As quatro formas como fundadores realmente usam flags

Repare que essas são ferramentas de produto e de marketing tanto quanto de engenharia. Acesso beta é uma conversa de vendas ("quer acesso antecipado?"). Liberação gradual é gestão de risco. Teste A/B é otimização da página de preços. O botão de emergência é seguro de sono.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

O argumento das 2h47 a favor das flags

Uma história real do meu próprio sistema em produção: 2h47 da manhã, o celular vibra com um alerta de taxa de erro. Endpoint falhando, usuários afetados. Duas opções — depurar meio dormindo ou voltar para a versão anterior em dois cliques. Voltei. Resolvido em 90 segundos, de volta para a cama, e depurei direito de manhã.

Um rollback é um instrumento bruto: ele reverte tudo daquele release — a funcionalidade quebrada e as três boas que foram junto. Uma feature flag é cirúrgica. Se a coisa quebrada está atrás de uma flag, você desliga só aquela funcionalidade e deixa o resto do release rodando. No melhor cenário, você nem chega a encarar a escolha das 2h47: a liberação gradual fez com que só 10% dos usuários vissem o bug, a flag foi desligada e a maioria dos seus clientes nem soube que algo aconteceu.

Os erros que fazem as flags darem errado

• Sem valor padrão. Você cria uma flag nova mas nunca define o que ela significa para os usuários existentes — eles recebem uma resposta indefinida e o app se comporta de um jeito que você não consegue reproduzir. Toda flag sai com um padrão explícito.
• Sem trilha de auditoria. O produto de repente se comporta diferente e ninguém sabe quem mexeu no quê, nem quando. Toda mudança de flag deve registrar quem, o quê, valor antigo, valor novo e horário — flags sem histórico são um pesadelo de depuração.
• Qualquer um pode mexer em qualquer coisa. Flags são controles de produção. Mudar uma flag no nível da organização deve exigir permissão de admin, exatamente como mudar a cobrança da organização.
• Consultar o banco de dados a cada requisição para checar a flag. Checagens de flag acontecem o tempo todo; precisam vir de um cache que se atualiza quando a flag muda, e não de uma consulta nova toda vez que uma página carrega.

Você precisa de flags desde o primeiro dia?

Mais cedo do que você imagina. Você não precisa de um produto sofisticado de flags — uma tabela de flags no seu próprio banco de dados, gerenciada por uma tela de admin simples, é o padrão que sustenta isso em qualquer escala. Ela faz parte do seu sistema de configurações, que a IA constrói rápido a partir de uma boa especificação; o mecanismo de flags em si é trabalho de algumas horas, não um projeto.

O retorno começa na sua primeira funcionalidade assustadora. Na primeira vez que você publicar algo no escuro numa terça, testar em produção a semana toda e "lançar" na segunda apertando um botão — vai se perguntar como alguém constrói sozinho sem isso.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Perguntas frequentes

Qual é a diferença entre uma feature flag e uma configuração?

Uma configuração guarda uma preferência — fuso horário, tema, moeda. Uma feature flag guarda uma decisão sobre disponibilidade: esta funcionalidade está ligada, e para quem? As duas vivem no mesmo sistema hierárquico (padrão global → sobrescrita da organização → sobrescrita do usuário), e é por isso que o mecanismo de flags costuma ser construído como parte do seu sistema de configurações.

Qual é a diferença entre uma feature flag e um rollback?

Um rollback reverte o deploy inteiro para a versão anterior — eficaz, mas derruba as mudanças boas junto com as ruins. Uma flag desliga uma funcionalidade específica e deixa todo o resto rodando. Você quer os dois: rollbacks como freio de emergência, flags como o controle de precisão que você usa primeiro.

Feature flags deixam o app mais lento?

Não, se estiverem em cache. A checagem da flag roda o tempo todo, então a resposta precisa vir de um cache que se atualiza quando uma flag muda — nunca de uma consulta nova ao banco a cada carregamento de página. Feito do jeito certo, o custo é praticamente zero.

Um fundador não técnico consegue gerenciar feature flags?

Esse é justamente o ponto. As flags tiram as decisões de lançamento do código e as levam para um painel: você decide quem vê o quê, e quando, sem mexer em deploy. Você comanda a liberação — 10% hoje, todo mundo na segunda — do mesmo jeito que agendaria uma newsletter.