An example of a feature flagging strategy for a cloud SaaS product uses four flag types — release flags (control rollout percentage), experiment flags (A/B test variants), ops flags (kill switches for production incidents), and permission flags (gate features by plan tier) — each with different ownership, lifetime, and cleanup criteria.
Most SaaS products start using feature flags reactively — someone adds a flag before a risky deploy, then another for an A/B test, then another for a beta program. Within a year the codebase has 200 flags with no consistent naming, no owners, and no clear lifecycle. This is flag debt, and it makes every deploy slower and every code review harder.
A feature flagging strategy prevents flag debt before it accumulates by defining flag types, ownership rules, and cleanup criteria before they are needed.
The Four Flag Types
Type 1: Release Flags
Purpose: Control the percentage of users exposed to a new feature during gradual rollout.
Lifetime: Short. Created at feature branch merge; removed within 30 days of 100% rollout.
Ownership: The PM and engineering lead who shipped the feature.
Example: feature_new_checkout_v2 — starts at 0%, increments to 5%, 25%, 50%, 100% over two weeks based on error rate monitoring.
Decision rule for rollout progression:
- Step from 0% to 5%: No error rate increase vs. control
- Step from 5% to 25%: Primary metric trending positive, no support ticket spike
- Step from 25% to 100%: 30-day retention for exposed cohort ≥ baseline
H3: The Gradual Rollout Pattern
Day 1: ████░░░░░░░░░░░░░░░░ 5%
Day 4: ████████████░░░░░░░░ 25%
Day 8: ████████████████░░░░ 50%
Day 14: ████████████████████ 100% → Remove flag
According to Lenny Rachitsky's writing on deployment practices, gradual rollout via feature flags is the most important technique for maintaining high deployment velocity without increasing production incident rate. "Teams that ship 10x per day without flags are playing Russian roulette. Teams that ship 10x per day with flags are just iterating."
Type 2: Experiment Flags
Purpose: Route users to different variants for A/B testing.
Lifetime: Medium. Duration of the experiment plus 2 weeks for analysis. Remove after decision.
Ownership: The PM running the experiment (works with data team to analyze).
Example: experiment_onboarding_v3_vs_v4 — 50% see V3 (control), 50% see V4 (variant). Runs until minimum sample size reached.
Critical rule: Experiment flags must be removed within 2 weeks of experiment conclusion regardless of outcome. Never let an experiment flag become a permanent code path.
Type 3: Operations Flags (Kill Switches)
Purpose: Instantly disable a feature or integration that is causing production issues without a deploy.
Lifetime: Permanent. Kill switches are infrastructure, not temporary.
Ownership: On-call engineering rotation. Documented in runbooks.
Example: ops_disable_third_party_payment_gateway — flipping this flag routes all payment traffic to the fallback processor within 30 seconds.
H3: Kill Switch Design Principles
Kill switches are the most important flags in a SaaS product. They must:
- Trigger in under 60 seconds of flag change (not dependent on cache expiration)
- Be tested monthly in non-production to confirm they still work
- Have a clear rollback procedure documented in the incident runbook
- Cover every third-party dependency that can cause a production incident
According to Shreyas Doshi on Lenny's Podcast, the products that recover fastest from production incidents are almost always the ones with well-designed kill switches. "The best incident management I've seen was a team that could neutralize the impact of an incident in under 2 minutes without a deploy. Kill switches made that possible."
Type 4: Permission Flags
Purpose: Gate features by subscription plan, customer tier, or beta program membership.
Lifetime: Long-lived. Exists as long as the plan differentiation exists.
Ownership: Product management. Linked to billing and entitlement system.
Example: permission_advanced_analytics_enterprise_only — only accounts on the enterprise plan see the advanced analytics module.
Flag Naming Convention
A clear naming convention is the foundation of flag hygiene:
{type}_{feature_area}_{description}
Examples:
feature_checkout_new_payment_ui
experiment_onboarding_skip_tutorial_variant
ops_disable_email_notifications
permission_reporting_executive_dashboard_enterprise
Benefits of consistent naming:
- Instant identification of flag type and owner
- Filterable in your flag management tool
- Clear scope for cleanup (all
feature_checkout_*flags >30 days old are candidates for removal)
The Flag Lifecycle and Cleanup Process
Flag debt accumulates when flags are created but never removed. Prevent this with:
H3: The Flag Debt Prevention Protocol
- Flag registry: Every flag entered in a registry with type, owner, creation date, and planned removal date
- Automated alerts: Flags older than their type's max lifetime trigger alerts to the owner
- Weekly cleanup ritual: 15 minutes in sprint planning to review flags scheduled for removal
- Quarterly audit: Review all flags >90 days old; any without a clear purpose are candidates for removal
According to Gibson Biddle on Lenny's Podcast, teams that treat flag cleanup as optional inevitably accumulate technical debt that slows every subsequent deploy. "I've worked with teams that had 400 active flags with no owners. Every deploy was a 2-hour investigation into which flags were active for which users. The cleanup took 3 months of engineering time."
Flag Management Tools
Recommended flag management platforms for cloud SaaS:
| Tool | Best for | Key strength | |------|----------|-------------| | LaunchDarkly | Enterprise SaaS | Full-featured, enterprise compliance | | Statsig | Experimentation-heavy teams | Integrated stats engine | | Growthbook | Open source option | No per-seat pricing | | Split.io | Complex targeting rules | Advanced user segmentation |
FAQ
Q: What is an example of a feature flagging strategy for a cloud SaaS product? A: A strategy using four flag types — release flags for gradual rollout, experiment flags for A/B tests, ops flags as kill switches, and permission flags for plan gating — each with distinct ownership, lifetime limits, and cleanup criteria.
Q: What are the four types of feature flags in a SaaS product? A: Release flags control gradual rollout percentage, experiment flags route users to A/B test variants, operations flags serve as kill switches for production incidents, and permission flags gate features by subscription plan or user tier.
Q: How do you prevent feature flag debt in a SaaS product? A: Establish a flag naming convention, maintain a flag registry with owner and planned removal date, set automated alerts for flags exceeding their type's maximum lifetime, and include a weekly cleanup ritual in sprint planning.
Q: What is a kill switch in feature flagging and why is it important? A: A permanent operations flag that can instantly disable a feature or third-party integration causing production issues without a deploy. Kill switches must trigger in under 60 seconds, be tested monthly, and have documented rollback procedures in incident runbooks.
Q: How long should different types of feature flags live? A: Release flags should live at most 30 days after reaching 100 percent rollout. Experiment flags should be removed within 2 weeks of experiment conclusion. Kill switches are permanent infrastructure. Permission flags live as long as the plan differentiation exists.
HowTo: Create a Feature Flagging Strategy for a Cloud SaaS Product
- Define the four flag types in your engineering documentation: release flags for gradual rollout, experiment flags for A/B tests, ops flags as kill switches, and permission flags for plan gating
- Establish a naming convention using the pattern type underscore feature area underscore description to make flags filterable and owner-identifiable
- Create a flag registry where every flag is recorded with type, owner, creation date, and planned removal date before it is deployed
- Set automated alerts for flags that exceed their type's maximum lifetime to prevent flag debt accumulation
- Design kill switches for every third-party integration that can cause a production incident, test them monthly, and document rollback procedures in incident runbooks
- Include a 15-minute weekly flag cleanup ritual in sprint planning and conduct a quarterly audit of all flags older than 90 days