A feature flag can begin as one of the smallest ideas in software:

if (newFeatureEnabled) {
  showNewFeature();
} else {
  showExistingFeature();
}

That small decision can eventually become part of how an organization separates deployment from release, runs experiments, protects production, changes runtime behavior, manages entitlements, and gradually exposes new capabilities.

This series follows that progression without assuming a particular framework or cloud. When implementation examples help, we will use familiar technologies such as React, Angular, Vue, Java, .NET, Node.js, Python, AWS Lambda, Azure Functions, iOS and Android. The concepts come first. The framework is only an example.

What this series is trying to answer

The early lessons answer the developer questions:

  • What is a feature flag?
  • Why not just deploy a different version?
  • What happens when a flag service is unavailable?
  • Where should evaluation happen?
  • How do frontend, backend, serverless and mobile applications differ?

The later lessons move into the questions organizations eventually face:

  • What is OpenFeature and what does it actually standardize?
  • How are GitLab, Datadog, LaunchDarkly, Harness and Unleash different?
  • How should cost be modeled?
  • Who is allowed to change a production flag?
  • How do we keep temporary flags from becoming permanent technical debt?
  • When should a rollout stop automatically because production health is degrading?
  • Should an enterprise standardize on one feature management control plane?

The learning path

Foundations

  1. Feature Flags Explained
  2. Feature Flags Are More Than On and Off
  3. What Is OpenFeature?

Building with Feature Flags

  1. Feature Flags in Frontend Applications
  2. Feature Flags in Backend Services
  3. Feature Flags in Serverless Applications
  4. Feature Flags in Mobile Applications
  5. Testing Applications That Use Feature Flags

Platforms

  1. The Feature Flag Platform Landscape
  2. GitLab Feature Flags
  3. Datadog Feature Flags
  4. LaunchDarkly
  5. Harness Feature Management and Experimentation
  6. Unleash and Open Source Feature Management

Decision and Operations

  1. How Organizations Choose a Feature Flag Platform
  2. GitLab vs Datadog Feature Flags
  3. Comparing Feature Flag Platforms
  4. The Real Cost of Feature Flags
  5. Operating Feature Flags at Scale
  6. Feature Flag Governance and Technical Debt

Architecture

  1. Designing an Enterprise Feature Management Architecture
  2. OpenFeature and Vendor Portability
  3. Feature Flags, Progressive Delivery, and Observability
  4. Feature Flags and Experimentation
  5. The Future of Runtime Configuration and AI Systems

A principle that will carry through the series

A feature flag is not automatically good architecture. It is a controlled form of runtime variability. That variability has value when it helps us release safely, learn, recover, or manage legitimate differences in behavior. It becomes a liability when nobody knows who owns the flag, what it protects, when it should be removed, or what happens when two flags interact.

The goal of this series is therefore not to encourage more flags. It is to understand when they are useful, how they should be implemented, and how to keep the control they provide from turning into another source of complexity.

Start with Feature Flags Explained →