93 posts tagged with "feature flags"

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.

In monolithic applications, every change requires redeploying the entire system. Now, imagine pushing a payment processing update to your e-commerce platform during peak traffic. A bug slips through. You deploy a fix. That fix introduces another issue. Suddenly, you're rolling back the whole application under pressure.

Microservices reduce that blast radius by breaking systems into smaller, independently deployable services. When you combine microservices with feature flags, you gain something even more powerful: the ability to change production behavior without redeploying code. If one service misbehaves, you don't redeploy. You disable the feature. You stabilize and fix forward. That level of runtime control is what makes feature flags essential in distributed systems.

In this guide, we'll explore how feature flags work in microservices and serverless architectures, and walk through a practical example using AWS Lambda, .NET, Redis, and ConfigCat.

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.

Manually recreating dozens of feature flags across platforms is tedious and error-prone. This guide shows you how to automate the entire migration from Prefab to ConfigCat in minutes using CLI export and natural language commands via an AI agent.

Rather than rebuilding every flag by hand, you'll export your entire Prefab configuration into a data file and use ConfigCat's AI-powered Model Context Protocol (MCP) server to transfer your configuration with minimal effort.

Prefab was acquired by Reforge and is being rebranded as Reforge Launch. If you're evaluating Prefab alternatives, ConfigCat offers a comparable feature set. With this simple migration process, you can see exactly how your Prefab feature flags behave in ConfigCat.

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.

Shipping fast is part of startup life. Breaking production doesn't have to be.

Early-stage SaaS teams face a unique challenge: they need to ship new features quickly, experiment often, and release continuously without risking production stability. Speed drives growth, but uncontrolled releases can lead to outages, technical debt, and lost user trust. That's why feature flags have become a core part of modern startup release management.

The ConfigCat Startup Program was created to help startups build with the right foundations from the beginning. It gives early-stage teams access to a production-ready feature flag service with startup-friendly pricing, so they can release safely while everything is still under construction.

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).

In this step-by-step guide, you’ll learn how to automate your Statsig feature flags migration with AI-powered Model Context Protocol (MCP) servers. Instead of writing custom scripts or manually recreating each flag, you can use natural language commands to transfer your entire configuration reducing migration time by up to 80%.

Most teams agree that reliability is learned in production, but the real challenge is learning without affecting the customer experience. After all, even well-designed systems fail in subtle ways: a single slow dependency can cascade into bottlenecks, or an overloaded database connection can push response times beyond what users will tolerate. We can wait for incidents to expose these cracks, or simulate them on our own with the help of feature flags.

Chaos engineering with feature flags offers a more controlled alternative. Instead of waiting for failures to happen, teams can deliberately inject small, realistic faults into production, limit their blast radius, and observe how systems behave under stress without risking a full-scale incident.

In this article, we'll look at how feature flags work, how they fit naturally into chaos engineering practices, and how chaos-enabled feature flags can help test production resilience through controlled failures.