Cleft Thinks Feature Flags Should Live in Your Git Repo, Not Some Third-Party Dashboard

The Macro: Feature Flags Are Essential and Also Kind of Annoying

Feature flags are one of those tools that every engineering team knows they should use and most teams implement badly. The concept is simple: wrap new functionality in a conditional so you can turn it on or off without deploying new code. In practice, the implementation gets complicated fast.

The market leaders are LaunchDarkly, which has raised over $330 million and serves the enterprise, and Split.io (now Harness Feature Flags after the acquisition). There is also Flagsmith, which offers an open-source option, and Unleash, another open-source player. On the cheaper end, you have ConfigCat and Flipt. Every major cloud provider has bolted on some version of feature management too.

Here is the problem with all of them: they require you to integrate an SDK into your application, maintain a connection to an external service, and manage your flags through a separate dashboard that lives outside your codebase. Your feature flags become a dependency. If LaunchDarkly goes down, your flag evaluations might fail. If you forget to clean up old flags in the dashboard, you end up with hundreds of stale toggles that nobody remembers the purpose of.

The deeper issue is conceptual. Feature flags are fundamentally about code behavior. They determine which code paths execute. But the current generation of tools treats them as infrastructure, which means they live in a completely different system from the code they control. That disconnect creates real problems at scale.

I have seen teams where the flag dashboard had over 400 flags, nobody knew which ones were still active, and removing any of them felt too risky because the dashboard did not map cleanly to the codebase. That is a governance failure enabled by architectural choices.

The Micro: Flags That Live Where Code Lives

Cleft takes a fundamentally different approach to feature flags. Instead of running a separate service with an SDK, Cleft embeds flags directly in your Git repository. The flags are part of your codebase. They version with your code. They get reviewed in pull requests. They follow your existing branching and deployment workflows.

This means no SDK to install, no external service to depend on, and no separate dashboard to manage. When you create a flag in Cleft, it exists as a configuration artifact in your repo. When you toggle it, that is a commit. When you clean it up, that is a deletion you can review in a diff.

The implications are significant for teams that care about auditability. Every flag change has a commit hash, an author, a timestamp, and a review trail. You get that for free because you are already using Git. With dashboard-based tools, you have to build separate audit logging.

The approach also eliminates an entire class of incidents. There is no external service that can go down and break your flag evaluation. There is no API latency to worry about. The flags are resolved at build time or from local configuration, depending on your setup.

The trade-off is obvious: you lose real-time flag toggling without a deployment. With LaunchDarkly, a product manager can flip a flag in the dashboard and it takes effect in seconds. With a git-native approach, changing a flag means committing a change and deploying it. For teams that practice continuous deployment, that gap might be thirty seconds. For teams with weekly release cycles, it could be days.

The Verdict

I think Cleft is asking a question that more teams should be asking: why are we running a separate piece of infrastructure for something that is fundamentally a code concern?

The git-native approach will not work for everyone. Teams that need instant flag toggling from a non-technical product manager will still want LaunchDarkly or something like it. Teams running long release cycles will find the commit-and-deploy workflow too slow for kill switches and gradual rollouts.

But for engineering teams that already deploy continuously, the value proposition is compelling. You eliminate a vendor dependency, you get better auditability for free, and your flags cannot drift out of sync with your code because they are your code.

In thirty days, I want to see adoption numbers among teams that are already doing trunk-based development. Those are the natural early adopters. In sixty days, the question is whether the no-SDK approach creates any gaps in functionality that teams actually miss. Can you do percentage rollouts? Can you target specific user segments? Those features matter and implementing them without an SDK is non-trivial. In ninety days, I want to see whether Cleft has attracted contributions from the open-source community or if it is still a small-team project. Git-native tools tend to either get adopted by the developer community or they do not. There is rarely a middle ground.

The feature flag market is crowded but also ripe for rethinking. LaunchDarkly built a great business by making flags easy to manage. Cleft is betting that the next evolution is making flags impossible to lose track of. I think that bet deserves attention.