Agentes de IA estão levando times a reconsiderar se vale a pena construir internamente ferramentas que hoje pagam como serviço. As feature flags sempre foram um alvo clássico dessa dúvida de “build or buy”, mesmo antes da IA ficar boa. O motivo: na forma mais básica, uma flag é uma função. Você a chama com uma chave e ela retorna um valor. Quão difícil pode ser?
A complicação está em tudo o que precisa acontecer para retornar esse valor de forma confiável, precisa e rápida. Times que avaliam construir ou comprar logo esbarram nos pontos óbvios: custa tempo e dinheiro criar, hospedar e manter; já existe muito software de feature flag no mercado, inclusive gratuito; quanto menos flags, usuários, SDKs e casos de uso, mais fácil gerenciar; e tornar flags utilizáveis exige mais do que a funcionalidade central, como uma interface administrativa.
Mas a decisão vai além desses pontos. A seguir, os fatores não óbvios que a PostHog, empresa que oferece feature flags para milhares de clientes, recomenda considerar.
O trabalho real está nas integrações
Uma implementação de feature flag começa simples: uma tabela de banco de dados com uma chave e um valor. Assim que você quer fazer mais, precisa integrar com outros serviços, e isso rapidamente vira a maior parte do trabalho. Alguns exemplos:
- Identificação de usuários. É preciso saber quem é o usuário para segmentá-lo com uma flag. Pode ser apenas um ID, mas também inclui propriedades como plano, localização, dispositivo e mais.
- Experimentação. Flags podem ser usadas para rodar experimentos, mas isso exige analytics de uso, log de exposição e análise estatística para determinar o impacto de cada valor da flag.
- Cohorts em tempo real. Calcular cohorts frequentemente não tem nada a ver com as flags em si. A participação pode mudar em uma parte completamente diferente do código. Race conditions podem adicionar ou remover membros na hora errada, e recalcular constantemente sai caro.
- Data warehouses. Para muitas empresas, a fonte da verdade é o data warehouse, mas ele quase nunca é otimizado para o tipo de consulta que as flags precisam fazer.
Errar nesses pontos não significa apenas flags que não funcionam: pode causar problemas nos serviços com os quais elas se integram. Imagine um serviço de flags usando uma tabela compartilhada com outros serviços. Uma query ruim pode vazar dados sensíveis. Uma requisição malformada pode travar a tabela e derrubar outras coisas.
Embora no código a implementação pareça uma única chamada de função, os dados para calcular o retorno podem vir de múltiplos serviços, e as queries e cálculos para obter o valor correto podem ser complexos. Acertar tudo isso exige um foco que times que constroem flags por conta própria talvez não tenham.
Flags no seu caminho crítico
Assim como a ciência avança um funeral por vez, a confiabilidade de feature flags avança um outage por vez.
Flags costumam estar no caminho crítico da aplicação. Um problema com elas pode significar usuários recebendo a experiência errada, ou nenhuma experiência. Em alguns casos, já custaram milhões a empresas.
Há muitos “unknown unknowns” ao construir um serviço de feature flags: problemas e pontos cegos que só aparecem em produção, como atingir os limites de eficiência do serviço principal, questões específicas de Rust causando picos de latência, ou consumir muito mais RAM do que o necessário.
Toda plataforma de flags já teve problemas, inclusive a PostHog. Todas aprenderam com os incidentes e melhoraram. A empresa afirma que seu p99 está hoje abaixo de 25 ms, com 100% de uptime nos últimos 90 dias (entre 17 de junho e 14 de setembro de 2026). É disso que você abre mão ao construir seu próprio serviço: os erros serão seus, e a responsabilidade de corrigi-los também, não de um fornecedor.
A arquitetura precisa ser à prova de futuro
Flags começam simples. Um toggle no banco de dados liga e desliga funcionalidades, mas novos recursos inevitavelmente serão adicionados. Você não será a única pessoa usando o sistema, e essas outras personas terão necessidades diferentes.
Uma estrutura que funciona no início pode estar errada depois. Adicionar segmentação básica por usuário a toggles de banco exige escrever um serviço inteiro novo, porque a avaliação deixa de ser somente leitura. Adicione segmentação por porcentagem e você precisa de bucketing determinístico, algo que talvez só perceba quando um usuário reclamar que uma feature sumiu.
E você está pronto para atender várias linguagens, inclusive as que domina menos? O Airbnb construiu um sidecar de Kubernetes especificamente para evitar reimplementar configuração em múltiplas linguagens. Reestruturações para comportar novos recursos frequentemente exigem reescritas e migrações arriscadas.
Nem empresas grandes escapam. O Dropbox construiu em 2017 seu próprio serviço de feature flags, o Stormcrow, com populações baseadas em Hive ligadas ao warehouse de analytics, grafo de inferência de seletores, entrega de configuração em JSON, entrega em lote para clientes mobile e desktop, monitoramento em tempo real, analisador estático para rastrear flags no código, histórico de auditoria e overrides. Ainda assim, em 2026, migraram para uma plataforma de flags.
Ergonomia para agentes
Agentes estão se tornando os principais usuários de feature flags. Cerca de 60% das flags do PostHog são criadas fora da interface, e 33% delas especificamente via MCP.
Os desenvolvedores do seu time vão querer usar agentes para criar e editar flags. Essa é uma superfície importante a manter, e significa que você precisa de:
- MCP com ferramentas
- CLI
- Controles de acesso para agentes
- Audit log
- Ferramentas de debugging
É mais uma frente onde surgem problemas. A PostHog relata casos em que agentes mexeram em flags que não deveriam, levando o cliente a reavaliar permissões de leitura versus escrita para agentes. Só foi possível entender o que aconteceu graças ao audit log.
Além disso, disponibilizar ferramentas para agentes não significa que elas serão usadas corretamente. A taxa de erro da ferramenta de flags via MCP da PostHog estava em torno de 5% no último mês por causa de chamadas malformadas e IDs alucinados. Com visibilidade de performance do MCP, a empresa conseguiu corrigir e reduzir esses erros, mas um time sem essa observabilidade desperdiçaria tempo e tokens a cada ocorrência.
Adoção, experiência do desenvolvedor e documentação
Em empresas grandes, adoção pode ser um problema legítimo. Dropbox e monday.com já escreveram sobre a fragmentação de ferramentas internas de desenvolvimento, que leva a várias soluções de qualidade variável fazendo as mesmas coisas.
Não tínhamos uma ferramenta, mas várias: algumas para o monólito, outras para microsserviços, sem diretrizes claras sobre qual usar, quando ou por quê. Não havia um caminho feliz, apenas um conjunto fragmentado de soluções e muito conhecimento não documentado. – Yoni Alaluf, Tech Lead na monday.com
Como qualquer ferramenta, os desenvolvedores precisarão ser convencidos a usar a sua. O que impede alguém de construir a própria ferramenta de feature flag para um caso de uso simples?
Uma parte central disso é documentação e experiência do desenvolvedor. Uma empresa como a PostHog pode investir nessa frente porque tem muita gente usando o produto, com times atualizando constantemente documentação, ferramentas para agentes e boas práticas. Isso dificilmente acontece com uma ferramenta construída internamente.
Quando faz sentido construir?
Apesar de todos os argumentos a favor da compra, construir ainda pode fazer sentido em alguns casos:
- Quando é um diferencial da empresa. Você vende feature flags, experimentos ou produtos relacionados como serviço.
- Você tem um time interno para manter. Mesmo sem vender flags, é preciso um time que trate a ferramenta como produto, responsável por novos recursos, correção de bugs e melhorias.
- Você não consegue parar de se preocupar com terceiros. Se há razões fortes para desconfiar de um fornecedor, seja por confiabilidade, compliance ou outros motivos, construir pode ser o único caminho que traz tranquilidade.
Fora desses critérios, a recomendação do artigo é avaliar as plataformas existentes. Empresas como Arena, ResearchGate e carVertical usam o PostHog para feature flags, com o primeiro 1 milhão de requisições por mês gratuito.
Artigo original: https://posthog.com/blog/build-or-buy-feature-flags
Traduzido e adaptado pela Equipe CRO Brasil