· NERVICO · digital-product · 11 min read
Feature Flags and Progressive Delivery: Deploying Without Fear
Practical guide to feature flags and progressive delivery. How to deploy features safely, reduce production risks, and accelerate delivery cycles without compromising stability.
Software deployment has a fundamental problem: the bigger the change, the greater the risk. And the more afraid the team is of risk, the less frequently it deploys. And the less frequently it deploys, the bigger the changes when they arrive. It is a self-reinforcing cycle that ends with teams deploying once a month with fear, instead of ten times a day with confidence.
Feature flags break this cycle. They allow you to separate code deployment from feature activation. You can deploy code to production without users seeing it, activate it gradually for a percentage of users, and revert it instantly if something fails. No rollbacks, no emergency hotfixes, no sleepless nights.
This article explains how feature flags work, how to implement progressive delivery in practice, and what mistakes to avoid so they do not become a new source of complexity.
What Feature Flags Are (And What They Are Not)
The Simple Definition
A feature flag is a condition in your code that determines whether a feature is active or not. In its most basic form it is a conditional:
if (featureEnabled("new-checkout")) {
showNewCheckout();
} else {
showOldCheckout();
}The difference from a normal conditional is that the flag value is controlled externally: from an admin panel, a configuration service, or a feature management tool. You do not need to deploy new code to enable or disable a feature.
What Feature Flags Are Not
Not a substitute for testing. Feature flags allow you to control deployment risk, not code quality. If you deploy code with bugs behind a flag, the bug is still there. It is just invisible until you activate the flag.
Not permanent configuration. A feature flag has a lifecycle. It is born when you develop a feature, lives while you roll it out gradually, and must die when the feature is fully deployed. Flags that are never removed become technical debt.
Not user permissions. Although you can use flags to control who sees what, feature flags do not replace a robust permissions system. They are temporary deployment control mechanisms, not authorization mechanisms.
The Four Types of Feature Flags
Not all flags are equal. Understanding the differences helps you manage them correctly.
1. Release Flags
Purpose: separate code deployment from feature activation.
Lifecycle: days to weeks. Must be removed when the feature is fully active.
Example: you have developed a new onboarding flow. You deploy it to production behind a flag. You activate it first for 5% of new users. If the metrics are good, you increase to 25%, then 50%, then 100%. When it reaches 100%, you remove the flag and the old code.
2. Experiment Flags
Purpose: A/B testing and controlled experimentation.
Lifecycle: weeks to months. Must be removed when the experiment concludes.
Example: you want to test whether a red button converts better than a blue one. You create a flag that randomly assigns users to group A (red) or group B (blue). After collecting sufficient data, you analyze the results and remove the flag.
3. Ops Flags (Operational Flags)
Purpose: control system behavior in production without deploying code.
Lifecycle: variable. Some are permanent.
Example: a flag that disables integration with an external service when that service has problems. Instead of your application failing, you degrade functionality in a controlled way. Another example: a flag that limits the number of requests to an expensive API when traffic is abnormally high.
4. Permission Flags
Purpose: give access to specific features for user segments.
Lifecycle: long, sometimes permanent.
Example: premium features available only to paying users, or early access to features for beta testers.
Progressive Delivery: The Complete Framework
Feature flags are a tool. Progressive delivery is the strategy that gives them meaning. Progressive delivery consists of deploying features gradually, measurably, and reversibly.
The Five Levels of Progressive Delivery
Level 1: Dark Launches
You deploy code to production but no user sees it. The code exists, it runs in the backend, but the interface does not change. This allows you to validate that the new code works correctly in production without user impact.
Level 2: Canary Releases
You activate the feature for a very small percentage of users (1-5%). You monitor key metrics: error rate, latency, conversion. If everything is fine, you advance to the next level. If something fails, you revert instantly.
Level 3: Staged Rollout
You gradually increase the percentage: 10%, 25%, 50%, 75%, 100%. At each stage you monitor and decide whether to advance, pause, or revert.
Level 4: Ring-Based Deployment
Instead of random percentages, you deploy by user “rings”: first the internal team, then beta testers, then early adopters, then all users. Each ring validates the feature before advancing to the next.
Level 5: Feature Experimentation
The most sophisticated level. Each deployment is an experiment with hypotheses, success metrics, and statistical analysis. You do not just deploy features; you measure their impact with scientific rigor.
Guardrail Metrics
Guardrail metrics are metrics you monitor during a progressive rollout to detect problems before they affect many users.
Technical metrics:
- Error rate (5xx, uncaught exceptions)
- Latency p50, p95, and p99
- CPU and memory usage
- Timeout rate on dependent services
Business metrics:
User experience metrics:
- Core Web Vitals (LCP, FID, CLS)
- Completion rate of critical flows
- Drop-off rate at key steps
The rule is simple: if any guardrail metric degrades significantly during the rollout, you pause or revert. You do not wait for a customer to complain. You do not wait for the support team to report problems. The metrics tell you before anyone else.
Practical Implementation
Option 1: Simple Flags With Configuration
For small teams deploying one or two features per month, simple feature flags based on environment variables or configuration files may be sufficient.
Advantages: no external dependencies, no cost, full control.
Limitations: you cannot segment by user, you have no management panel, changes require redeployment.
When to use it: MVP with fewer than 10,000 users and a team of fewer than 5 developers.
Option 2: Open Source Tools
For teams that need user segmentation, rollout percentages, and a management panel without paying license fees.
Main tools:
- Unleash: mature open source, self-hosted, with SDKs for major languages
- Flagsmith: open source with cloud option, API-first, good management panel
- GrowthBook: open source specialized in experimentation and A/B testing
Advantages: full data control, no license costs, customizable.
Limitations: requires own infrastructure, team maintenance.
Option 3: Commercial Platforms
For teams that need advanced functionality without managing infrastructure.
Main tools:
- LaunchDarkly: market leader, deep integration with development tools
- Split.io: focused on experimentation and impact metrics
- Statsig: combines feature flags with automated statistical analysis
Advantages: advanced features, guaranteed scalability, support.
Limitations: significant monthly cost (from 500 to several thousand dollars per month), vendor dependency.
Implementation Best Practices
Consistent naming. Use a clear convention for naming flags: [team]-[feature]-[type]. Example: checkout-new-payment-flow-release. This facilitates search and maintenance.
Owner for each flag. Each flag must have an owner responsible for its lifecycle. When the owner changes teams or leaves the company, the flag becomes orphaned and turns into technical debt.
Expiration date. Each flag (except permanent operational ones) must have a planned expiration date. If that date passes and the flag is still active, it is a signal that something failed in the process.
Safe defaults. If the feature flag system fails (and it will), the default value of the flag must be the safe behavior. Normally, the default is “disabled” for release flags and “control” for experiment flags.
Common Mistakes and How to Avoid Them
Mistake 1: Flags That Are Never Removed
This is the most common and most costly long-term mistake. Each flag that remains in the code after fulfilling its purpose adds complexity. Two flags create 4 possible states. Ten flags create 1,024 possible states. No team can test 1,024 combinations.
Solution: establish a cleanup policy. Each release flag must be removed within two weeks of reaching 100% rollout. Add automatic alerts when a flag exceeds its expiration date.
Mistake 2: Flags That Are Too Granular
Putting a flag on every line of code is not progressive delivery. It is chaos. Flags should encapsulate complete features or coherent changes, not code fragments.
Solution: one flag per user-visible feature, not one flag per technical component.
Mistake 3: Not Monitoring During Rollout
Deploying to 5% and moving directly to 100% without checking metrics nullifies the purpose of progressive delivery. If you do not monitor, you are doing a normal deployment with extra steps.
Solution: define guardrail metrics before the rollout. Automate alerts. Do not advance to the next percentage until metrics confirm everything is working well.
Mistake 4: Insufficient Testing of Flag Combinations
If you have 5 flags active simultaneously, you need to consider the interactions between them. Flag A may work perfectly alone. Flag B as well. But activating A and B together may produce unexpected behavior.
Solution: minimize the number of simultaneously active flags. When you need several active flags, test the most likely combinations.
Mistake 5: Using Flags as an Excuse Not to Test
“We do not need thorough testing because we have flags and can revert.” This mentality turns production into a testing environment. Flags reduce deployment risk, not bug risk.
Solution: maintain your testing standards. Flags are a safety net, not a substitute for quality.
Feature Flags and Product Teams
How Flags Change the Relationship Between Product and Development
Without feature flags, the product team asks “when will it be ready?” and the development team responds with a date that depends on multiple uncontrollable variables. With feature flags, the conversation changes:
Without flags: “The feature will be ready on March 15. That day we launch it to all users.”
With flags: “The code will be deployed this week. When and for whom we activate it is a product decision we can make independently.”
This separation is transformative. The development team can deploy at their natural cadence without waiting for product to “approve” the launch. The product team can control activation according to business strategy without depending on a technical deployment.
Use Cases for Product Managers
Coordinated launch with marketing. The code is deployed and ready. Marketing prepares the campaign. When everything is aligned, the product manager activates the flag. No coordination with the development team on launch day.
Closed beta with selected users. You activate the feature only for a segment of users: the most engaged, those who need the feature most, or those who have expressed interest. You collect feedback before the general launch.
Kill switch for emergencies. If a feature generates unexpected problems (overwhelmed support, user complaints, performance impact), the product manager can disable it immediately without needing the development team.
Implementing Progressive Delivery Step by Step
Step 1: Choose the Right Tool
For most teams starting out, an open source tool like Unleash or Flagsmith is sufficient. If your team has fewer than 5 developers and deploys fewer than 5 features per month, even environment variables can work temporarily.
Step 2: Start With a Simple Release Flag
Do not try to implement full progressive delivery from day one. Start with a simple case: the next feature you are going to launch, put it behind a flag. Deploy the code. Activate the flag for the internal team. Then for 10% of users. Then for 100%.
Step 3: Define Your Guardrail Metrics
Before the first real rollout, define which metrics you will monitor and what thresholds indicate a problem. Configure automatic alerts for those thresholds.
Step 4: Establish the Rollout Process
Document the rollout steps: who decides to advance, which metrics are reviewed, how long to wait at each percentage, who can revert, and under what conditions.
Step 5: Implement Flag Cleanup
From the first flag, establish the removal process. Who removes the flag? When? How is it tracked that it was removed correctly?
Step 6: Scale Gradually
Once the process works for release flags, expand to experimentation. Then to operational flags. Each type introduces additional complexity that you must manage consciously.
Success Metrics for Your Progressive Delivery System
How do you know if progressive delivery is working? These metrics tell you:
Deployment frequency. How often do you deploy to production per week? Teams with mature progressive delivery deploy daily or multiple times per day.
Lead time for changes. How much time passes from when a developer commits to when the change is in production? With progressive delivery this should decrease significantly.
Change failure rate. What percentage of deployments cause problems in production? With progressive delivery and guardrail metrics, this percentage should decrease.
Time to recovery. If a deployment causes problems, how long does it take to revert? With feature flags, reversion should be instantaneous (seconds, not minutes or hours).
Number of active flags. How many flags are active at any given time? If the number grows without control, you have a management problem. For most teams, 10-20 active flags is a healthy range.
Conclusion
Feature flags and progressive delivery are not sophisticated technologies reserved for large companies. They are practices that any team can adopt gradually, starting with a simple release flag and evolving toward a complete progressive deployment system.
The key is to start simple, maintain discipline in flag cleanup, and monitor during every rollout. Most teams that fail with feature flags do not fail because of the technology. They fail because they accumulate flags without removing them, do not monitor during rollout, or use flags as an excuse not to test.
Start with one flag. One gradual rollout. A few basic metrics. And build from there. The goal is not to have the most sophisticated progressive delivery system. It is to deploy with confidence and revert with speed.
Need help implementing progressive delivery for your team?
At NERVICO we help product teams design and implement progressive deployment strategies adapted to their context. From tool selection to process definition, we can help you deploy more frequently with less risk.
