What's a Feature Flag? A Developer's Guide to Safer Releases

It's Friday, quarter to 5:00 PM. Your team, who likes to live dangerously, deploys a major checkout redesign to prod. Within minutes, conversion rates plummet by 30%. Your CEO is asking questions. Your phone is blowing up. Weekend plan? Fuhgeddaboudit.

Now imagine the same scenario, but with one key difference—you can fix the problem in 10 seconds with a single click. No emergency rollback, no frantic code reverts, no ruined weekends. That's the power of feature flags.

Feature flags, also known as feature toggles, are conditional statements in your code that let you turn functionality on or off without deploying new code. At their simplest, they're if/else blocks that check a configuration value to decide which code path to execute.

Here's what a feature flag looks like in practice:

{/* React SDK */}
const newCheckout = useFeatureIsOn("new-checkout")

if (newCheckout) {
  return <NewCheckoutFlow />;
} else {
  return <LegacyCheckout />;
}

Instead of deploying new code and hoping for the best, you deploy the code with the feature turned off, then enable it when you're ready. If something goes wrong, you can disable the feature instantly—no rollback required.

How Feature Flags Work

Feature flag systems have 3 main components that work together to give you complete control over your features:

1. Flag Configuration

A management system where you define flags and their rules. This could be a simple config or a full platform like GrowthBook:

{
  "new-checkout": {
    "defaultValue": false,
    "rules": [
      {
        "condition": {
          "$and": [
            {
              "accountAge": {
                "$gt": 30
              },
              "regionRestricted": false,
              "country": "GB"
            }
          ]
        }
      }
    ]
  }
}

2. SDK Evaluation

Your application checks flag states using an SDK:

// Initialize with user attributes
const gb = new GrowthBook({
  attributes: {
    id: user.id,
    country: user.country
  }
});

// Check flag state
if (gb.isOn("new-checkout")) {
  // New feature code
}

3. Flag Delivery

How flag updates reach your application—through API calls, streaming updates, or cached configurations. This is what enables that magical "instant rollback" capability.

Why Teams Use Feature Flags

Decouple Deployment from Release

Ship code when it's ready, release features when you want. Your main branch can contain unreleased features safely wrapped in flags. This means developers can merge code continuously without worrying about breaking production—the feature simply stays off until you're ready.

Reduce Risk with Progressive Rollouts

Instead of releasing to everyone at once, start with 5% of users. Monitor key metrics like conversion rates, error rates, and performance. If everything looks good, gradually increase to 25%, then 50%, then 100%. If issues arise, the blast radius is limited to a small subset of users.

Real-world example: A major e-commerce platform rolled out a new recommendation engine to just 2% of traffic initially. They caught a performance issue that would have brought down their entire site during Black Friday. The progressive rollout saved them millions in potential lost revenue.

🦺

GrowthBook includes Safe Rollouts, which automatically monitor your guardrail metrics and roll back features if they detect problems—even when you're not watching.

Test in Production Safely

Staging environments never perfectly mirror production. They lack real user behavior, real data volumes, and real traffic patterns. Feature flags let you test with actual production conditions while limiting exposure to a controlled group.

Consider testing a new payment processor integration—staging can't replicate the complexity of real payment flows, international regulations, or peak traffic loads. With feature flags, you can test with real transactions from a small percentage of users, gathering authentic feedback before full deployment.

Instant Rollbacks

When things go wrong (and they will... at the worst possible time 😅), you can disable a problematic feature immediately. No emergency deployments, no reverting commits, no waiting for CI/CD pipelines to complete their 20-minute build process.

Companies using feature flags report reducing their mean time to recovery (MTTR) from 45+ minutes to under 30 seconds. That's not just a technical improvement—it's a business advantage that prevents revenue loss and maintains customer trust.

Gateway to A/B Testing and Experimentation

Feature flags are the natural foundation for experimentation. Once you can control who sees what features, measuring impact becomes straightforward:

const variant = gb.getFeatureValue("checkout-cta-text", "Buy Now");
// Returns "Buy Now", "Purchase", or "Add to Cart" based on experiment allocation

Teams often start with simple on/off flags, then evolve into sophisticated experiments that drive product decisions with data rather than opinions.

Types of Feature Flags

Understanding the different types helps you implement the right approach for each use case:

Release Flags

Temporary flags for rolling out new features. Remove them after full deployment:

if (gb.isOn("dark-mode-beta")) {
  enableDarkMode();
}

Lifecycle: Create → Test → Rollout → Remove (typically 2-8 weeks)

Ops Flags

Control system behavior and configuration without code changes:

const cacheTimeout = gb.getFeatureValue("redis-cache-ttl", 300);
const rateLimit = gb.getFeatureValue("api-rate-limit", 1000);

Lifecycle: Long-lived, adjusted based on system needs

Permission Flags

Also referred to as "entitlements," these flags manage feature access for different user segments:

// Targeting sets flag to on when user has a premium account
if (gb.isOn("advanced-feature")) {
  enableAdvancedFeature();
}

Lifecycle: Permanent, tied to business logic

Experiment Flags

Test multiple variations to optimize your product:

const headerColor = gb.getFeatureValue("header-color", "blue");
// Might return "blue", "green", or "red" for different users

Lifecycle: Create → Run experiment → Analyze → Implement winner → Remove

Getting Started with GrowthBook

GrowthBook is an open source feature management and experimentation platform. Here's how to implement your first flag in a React app under 10 minutes:

1. Install the SDK

npm install @growthbook/growthbook-react

2. Initialize GrowthBook

import { useEffect } from "react";
import { GrowthBook, GrowthBookProvider } from "@growthbook/growthbook-react";

// Create a GrowthBook instance
const gb = new GrowthBook({
  clientKey: "sdk-abc123",
  enableDevMode: true,
  // Only required for A/B testing
  // Called every time a user is put into an experiment
  trackingCallback: (experiment, result) => {
    console.log("Experiment Viewed", {
      experimentId: experiment.key,
      variationId: result.key,
    });
  },
});

gb.init({
  // Enables real-time, instant updates to feature flags
  streaming: true
})

export default function App() {
  useEffect(() => {
    // Set user attributes for targeting (from cookie, auth system, etc.)
    gb.setAttributes({
      id: user.id,
      company: user.company,
    });
  }, [user])

  return (
    <GrowthBookProvider growthbook={gb}>
      <OtherComponent />
    </GrowthBookProvider>
  );
}

3. Create a Feature Flag

In the GrowthBook UI:

Navigate to Features → Add Feature
Set a unique key: new-onboarding
Choose type: boolean
Configure targeting rules

4. Use the Flag in Your Code

function OnboardingFlow() {
  if (gb.isOn("new-onboarding")) {
    return <SimplifiedOnboarding />;
  }
  
  return <ClassicOnboarding />;
}

Ready to see it in action? Try GrowthBook Cloud free and have your first flag running in minutes.

Advanced Targeting and Rollout Strategies

Feature flags become powerful when combined with sophisticated user targeting. GrowthBook lets you create rules that go far beyond simple on/off switches:

Percentage Rollouts

Gradually release a feature value to a random sample of your users, while ensuring users always see the same variant.

Force Rule

Target specific user segments with complex conditions:

Safe Rollout

Gradually release a new feature while monitoring guardrail metrics and rollback automatically if they fail.

Feature Flags + Experimentation

GrowthBook combines feature flags with a powerful experimentation platform, perfect for when you're not just shipping features but measuring their impact:

Instead of guessing whether a change improves your product, you can measure it directly. The data flows to your existing data warehouse, where GrowthBook's statistics engine analyzes results automatically. No data export needed—it reads from your existing tables.

This integration means you can start with a simple feature flag and evolve it into a sophisticated experiment without changing your code structure.

Best Practices That Actually Matter

Name Flags Clearly

Use descriptive names that explain what the flag controls:

// ❌ Bad
gb.isOn("ff-123")
gb.isOn("test")

// ✅ Good
gb.isOn("simplified-checkout")
gb.isOn("holiday-sale-banner")

Clean Up Old Flags (Ruthlessly)

Feature flags are technical debt. After a feature is fully rolled out:

Remove the flag checks from your code
Delete the flag from your management system
Document why it was removed

"Temporary" flags have a way of becoming permanent if you're not vigilant.

GrowthBook provides tools to help you here by:

Automatically surfacing stale flags using a sophisticated heuristic
Showing exactly where the flag lives in your codebase

Monitor What Matters

Don't just monitor technical metrics—watch business metrics too:

Technical: Error rates, response times, resource usage
Business: Conversion rates, revenue per user, customer satisfaction

Plan for Failure

Before you roll out any flag, have a rollback plan:

What metrics indicate problems?
Who has permission to disable the flag?
What's the communication plan if things go wrong?

Open Source Advantage

Unlike most solutions on the market, GrowthBook is open source. This means:

No vendor lock-in: Your feature flag and experimentation system isn't held hostage by a vendor. You can always export your data and configurations.
Self-hosting option: Keep your data in your infrastructure. Perfect for companies with strict compliance requirements.
Transparency: Inspect the code, understand exactly how flags evaluate, with full access to the experiment statistics engine. No black box algorithms making decisions about your features.
Customization: Modify the platform to fit your needs. Add custom targeting rules, integrate with internal systems, or adjust the UI.
Cost control: Predictable pricing with no penalty for actually using flags or running experiments. Some vendors charge per flag evaluation—imagine getting a surprise bill because your traffic spiked.

You can run GrowthBook on your infrastructure:

# docker-compose.yml
version: "3"
services:
  mongo:
    image: "mongo:latest"
    environment:
      - MONGO_INITDB_ROOT_USERNAME=root
      - MONGO_INITDB_ROOT_PASSWORD=password
    volumes:
      - mongodata:/data/db
  growthbook:
    image: "growthbook/growthbook:latest"
    ports:
      - "3000:3000"
      - "3100:3100"
    depends_on:
      - mongo
    environment:
      - MONGODB_URI=mongodb://root:password@mongo:27017/growthbook?authSource=admin
    volumes:
      - uploads:/usr/local/src/app/packages/back-end/uploads
volumes:
  uploads:
  mongodata:

Or use our Cloud version to get started immediately 🏎️

Common Pitfalls to Avoid

Flag Sprawl

Too many flags make code hard to understand and maintain. Set a team limit (like 50 active flags) and enforce regular cleanup.

Long-Lived Flags

"Temporary" flags that become permanent create technical debt. Set expiration reminders when creating flags and treat removal as seriously as creation.

Client-Side Security

Never use client-side feature flags for security. Malicious users can modify flag values:

// ❌ Wrong - anyone can enable this
if (gb.isOn("admin-panel")) {
  showAdminPanel();
}

// ✅ Right - verify permissions server-side
if (await checkAdminPermissions(user.id)) {
  showAdminPanel();
}

🔒

GrowthBook offers remote evaluation, encrypted features, server-side evaluation, and other security-minded features.

Build vs Buy

Should you build your own feature flag system or use a platform?

Build if you:

Have very simple needs (< 10 flags)
Cannot use third-party systems
Have dedicated engineering time to maintain the system
Need custom logic that no platform supports

Use a platform if you:

Want to start immediately
Need advanced targeting and rollout rules
Want built-in experimentation capabilities
Inclined to use tools for debugging and inspection
Prefer to focus on your product
Need collaboration features for non-technical team members

Next Steps

Feature flags fundamentally change how teams ship software. Start small—pick one risky feature and wrap it in a flag. Experience the confidence of deploying without fear, the power of instant rollbacks, and the insights that come from measuring real user behavior.

With GrowthBook, you get the complete package:

Open source transparency: See exactly how everything works, no black boxes
Your data, your warehouse: Analytics run on your existing data infrastructure
Full experimentation platform: Go beyond flags to measure impact and optimize features
Battle-tested reliability: Used by thousands of companies shipping millions of features
Community-driven development: Features requested and built by real users

Ready to transform how your team ships? Try GrowthBook Cloud free or check out our documentation to get started. For teams that prefer self-hosting, our GitHub repo has everything you need.

Feature flags aren't just a deployment technique—they're a competitive advantage. Companies that can ship faster, with less risk, and measure impact accurately will outpace those that can't. The question isn't whether you should use feature flags, but how quickly you can get started.

What are Feature Flags?