Csilla Kisfaludi

Feature flags make it easy to change application behavior quickly. But some changes (especially in Production) need an extra pair of eyes or need to happen at exactly the right time. To make both of these situations easier to manage, we’re introducing two of the most requested ConfigCat features: Approval Flow and Scheduled Changes.

With Approval Flow & Scheduled Changes, you can now propose feature flag changes for review, require approval before they reach an environment, and schedule changes to go live automatically at a specific time.

Together, they make it easier to review important changes and release them at the right time without slowing down everyday feature flag management.

A feature can work perfectly and still make the product worse. Imagine your team builds a new search-ranking algorithm that performs well in internal tests. Instead of releasing it to everyone, you can use a feature flag to show it to a percentage of users and compare how they behave.

Feature flags control who receives each variation, while your analytics platform measures the outcome. Together, they make it possible to test meaningful product changes, limit risk, and roll out the winning version without another deployment.

Feature flags save lives (okay, at least your weekends). They let you release features safely, test ideas with real users, and roll back when things break.

LaunchDarkly is the biggest name in the game, but it's not always the best fit. Maybe you need simple pricing, zero data collection, or an open-source option you can self-host. The good news: there are amazing LaunchDarkly alternatives out there.

In this guide, we compare some of the best LaunchDarkly alternatives in 2026, including ConfigCat, Flagsmith, Harness, Unleash, PostHog, Statsig, GrowthBook, and DevCycle.

Feature flags are one of those tools everyone loves… until it’s time to decide who actually controls them.

Should Engineering keep them because they built the feature? Should Product take over because they’re responsible for launches and customers? Or should both teams share ownership, set some clear rules, and avoid turning every rollout into a small internal debate?

The honest answer is: both Product and Engineering should own feature flags, but not in the same way.

Engineering should own the technical side: implementation, safe defaults, stability, and rollback. Product should own the rollout side: launch timing, user targeting, customer exposure, and experiments.

That sounds simple enough. But in real life, this is where things often get messy. So let’s break it down.

You’ve probably heard the term feature flag, maybe in a pull request review, a deployment postmortem, or a job description. The concept sounds simple: turn features on and off without redeploying code. But once you start working with them, you realize there’s a lot more to it than a boolean in a config file. They fundamentally change how you ship software.

This guide explains what feature flags actually are, how they work under the hood, when to use them, when not to use them, how to test them properly, how to manage them across teams, and how to avoid the organizational problems that turn a helpful tool into a maintenance burden.

Feature flags (also called feature toggles) let development teams release features safely without redeploying code. They power gradual rollouts, A/B testing, and fast rollbacks when things go wrong.

But as systems grow, feature flags often become a source of hidden complexity. Flags pile up, naming breaks down, and unclear ownership leads to risky changes in production. What starts as a simple toggle system can quickly turn into long-term technical debt.

This guide walks through seven common feature flag mistakes and the best practices to avoid them, so your system stays clean, predictable, and safe to work with.

When shipping new features, releasing them to all users at once can be risky. Even small bugs can affect thousands of users immediately. That's why modern teams rely on canary releases and feature flags to roll out changes gradually, monitor real-world performance, and reduce the risk of failure.

In this guide, you'll learn:

• What a canary release is
• How it works with feature flags
• A step-by-step rollout strategy using ConfigCat
• Best practices and common mistakes to avoid

If you’ve ever wished your feature flag values worked more like enums, this update is for you.

Over the past years, we kept hearing the same request in different forms:

• “Can we have enum-like values for feature flags?”
• “Can we avoid people mistyping values?”
• “Can we define JSON values once and just select it?”
• “Can we separate flag definitions from rollouts?”

This usually came up when teams started using multivariate feature flags or working with more complex JSON feature flags.

Free-form values are flexible. But when feature flags become operational tools, toggled by Customer Success, Sustainment teams, or junior teammates, flexibility without guardrails becomes a risk.

So we built Predefined variations.

The feature flagging and experimentation space is heating up fast. OpenAI’s acquisition of Statsig shows just how important feature flag management has become and signals that the industry is moving toward AI-assisted, data-driven systems that optimize every release automatically.

This isn’t just another headline in the AI news cycle. It’s a sign of where software delivery is heading: toward AI-assisted, data-heavy development workflows where every release is measured, analyzed, and optimized.

For some teams, that’s the dream. For others, it’s just another layer of complexity standing between them and shipping code.

We've been working on some updates to make the ConfigCat dashboard easier and more enjoyable for managing your feature flags. Let's take a quick look at these new features.