Lekko

Every tunable value lived in the repository next to the code that read it. That placement made configuration reviewable in a pull request, and it meant a bad change could be reverted like any other commit. The alternative, clicking through a vendor dashboard, leaves no trace in the codebase.

The SDK pulled a compiled bundle and evaluated rules locally, so a flag check cost microseconds instead of a network round trip. Services kept working when the control plane was unreachable, which removed a common failure mode of hosted feature flags. The tradeoff is that clients carry the evaluation logic and the bundle size grows with the rule set.

Lekko's tooling read an existing codebase, found flag references and suggested typed replacements. It also surfaced flags that no code path read anymore, the kind that linger for years after a launch. This was the clearest answer to the flag debt problem that hosted vendors tend to profit from.

Product managers and support leads could change approved values in the browser without touching a repo. Permissions decided which namespaces a person could edit, and every change landed as a reviewable record. The split worked because engineers defined what was safe to change and everyone else picked within those bounds.

Values had a declared type, and the CLI validated rules before they shipped, so a string could not quietly replace a number in production. Constraints like ranges and allowed lists were part of the definition. Teams that had been burned by a typo in a JSON flag payload tended to care about this more than any dashboard feature.

Access control ran per namespace, with roles for readers, editors and admins. Each change recorded who made it, what the previous value was and which commit or session produced it. For regulated teams, that record was often the difference between shipping a config change and waiting a week for approval.