Lekko

Cada valor ajustável ficava no repositório, ao lado do código que o lia. Esse lugar tornava a configuração revisável em um pull request e permitia reverter uma mudança ruim como qualquer outro commit. A alternativa, clicar no painel de um fornecedor, não deixa rastro no código.

O SDK baixava um pacote compilado e avaliava as regras localmente, então checar um flag custava microssegundos e não uma ida e volta pela rede. Os serviços continuavam funcionando quando o plano de controle não respondia, o que elimina uma falha comum dos feature flags hospedados. O preço disso: o cliente carrega a lógica de avaliação e o pacote cresce junto com o conjunto de regras.

As ferramentas do Lekko liam um código existente, encontravam referências a flags e sugeriam substitutos tipados. Também apontavam os flags que nenhum caminho do código lia mais, daqueles que sobrevivem anos depois do lançamento. Era a resposta mais direta ao problema da dívida de flags, justamente o terreno em que os fornecedores hospedados costumam lucrar.

Product managers e lideranças de suporte mudavam valores aprovados pelo navegador sem tocar no repositório. As permissões definiam quais namespaces cada pessoa podia editar, e toda mudança ficava registrada. A divisão funcionava porque os engenheiros definiam o que era seguro alterar e os demais escolhiam dentro daquele limite.

Os valores tinham tipo declarado e a CLI validava as regras antes da publicação, então uma string não substituía um número em produção sem aviso. Faixas permitidas e listas de opções faziam parte da definição. Quem já apanhou de um erro de digitação em um JSON de flags dava mais valor a isso do que a qualquer painel.

O controle de acesso funcionava por namespace, com papéis de leitura, edição e administração. Cada mudança registrava quem fez, qual era o valor anterior e qual commit ou sessão a produziu. Em times regulados, esse registro era a diferença entre publicar uma configuração e esperar uma semana por aprovação.