88 posts tagged with "feature management"

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.

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

Bun is making waves in the JavaScript ecosystem. This speedy new toolkit promises faster startup times, native TypeScript support, and improved performance compared to Node.js. But as Bun gains adoption, developers require modern tooling to match its capabilities. Feature flags are one such tool, and are perfect for Bun applications.

Coming up, we'll learn what Bun is and how it compares to Node.js, then dive into using ConfigCat feature flags in Bun projects. Finally, we'll discuss how to safely roll out new features, A/B test them, and quickly fix problems in production, all with the help of feature flags.

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.

At ConfigCat, we use the best feature flag provider in the world. Plot twist: it's ConfigCat. We're basically in a committed relationship with ourselves. Some call it narcissism; we call it quality control.

In this article, we'll share real-world feature flag examples from production, explain how we use our own system inside ConfigCat, and confess the biggest feature flag mistake we've ever made (so you don't have to repeat it).

Releasing new features in a mobile app can feel like walking a tightrope, especially when updates require going through lengthy App Store and Google Play review processes, and users still need to download the new build. That's where feature flags come in. They are software development tools that give developers the power to toggle features remotely, test new functionality safely, and control rollouts without shipping a new app version.

This guide shows you how to use feature flags in Flutter (Dart) with ConfigCat, focusing on best practices, manual polling, offline support, and real-world examples.

Software development can be challenging, but deploying and managing new features shouldn't be. With feature flags, you can rest assured that your updates and new features are delivered safely with minimal risk. In this guide, I'll show you how to integrate a feature flag into a NestJS application.

Before the open source movement, software programs were 'closed source,' meaning only software developers employed by the company could access and modify them. Outsiders were kept out through non-disclosure agreements and licenses. This exclusivity motivated the creation of the open-source movement, aiming to preserve the freedom to modify and distribute software through publicly accessible code. Today, many commercial companies actively participate in the open-source ecosystem, maintaining software that is open to the public for access and contributions. One such company supporting this effort is ConfigCat.

When it comes to shipping features fast and confidently, feature flags are your secret weapon. They let you roll out updates safely, test in production, and avoid deployment risks. But here's the big question: should you build your own feature flag system, or choose a ready-made solution like ConfigCat?