Feature Flag Provider Selection¶
- Status: Proposed
- Deciders: emmjoh, brishe
- Date: 2026-02-27
Context and Problem Statement¶
SAIF applications currently have no centralized feature flag system. Individual teams manage feature toggles ad hoc, making it impossible to achieve same-day deployments, progressive rollouts, or consistent experimentation practices across the platform. A standard approach is needed that aligns with the Forge platform principles: managed services over self-hosted, Azure-native where practical, and minimal operational overhead for product teams.
Decision Drivers¶
- Alignment with Forge platform principle of preferring managed PaaS services over self-hosted or custom-built solutions
- Cost effectiveness at scale (100+ backend services, 20–50 developers)
- First-class .NET and TypeScript SDK support to match SAIF's primary application stacks
- Integration with existing Azure infrastructure (Entra ID, Key Vault, Terraform, Dynatrace)
- Local-first development support — developers must be able to work offline without a cloud dependency
- Compliance and security certifications appropriate for a financial services organization
Considered Options¶
- Azure App Configuration (Feature Management)
- LaunchDarkly
- GrowthBook (Cloud or Self-Hosted)
- Unleash (Cloud or Self-Hosted)
- Build a custom feature flag system
- No change — leave feature management to individual teams
Decision Outcome¶
Chosen option: Azure App Configuration (Feature Management), because it is a fully managed Azure-native PaaS service that meets 90%+ of SAIF's feature flag requirements at 15–30× lower cost than the next viable commercial alternative, integrates seamlessly with existing platform infrastructure (Entra ID, Key Vault, Terraform), and extends an Azure App Configuration deployment that is already in use across SAIF services — requiring no new vendor relationship or infrastructure footprint.
Consequences¶
- Good, because Azure App Configuration is already deployed on a shared subscription; adding feature flags extends existing infrastructure with no additional provisioning cost.
- Good, because the Microsoft Feature Management library (.NET) and TypeScript SDK are mature, actively maintained, and well-documented with official Microsoft Learn guidance.
- Good, because managed identity authentication eliminates secret management for feature flag access.
- Good, because real-time flag updates (SignalR or polling), percentage-based rollouts, Entra ID group targeting, and feature variants for A/B testing are all built-in capabilities.
- Good, because consumption-based pricing keeps ongoing costs at ~$40–75/month for 100 services (~$900/year), compared to $14,400–60,000/year for LaunchDarkly.
- Good, because local development can fall back to
appsettings.Development.jsonoverrides, preserving local-first development parity without requiring a cloud connection. - Bad, because Azure App Configuration is Azure-optimized; applications deployed to AWS or other clouds require cross-cloud HTTPS access or future provider migration.
- Bad, because SDK caching introduces a configurable propagation delay (typically 30 seconds to a few minutes) between flag updates and application behavior changes.
- Bad, because LaunchDarkly and GrowthBook offer richer experimentation UIs and A/B testing workflows; teams with advanced experimentation needs may find Azure App Configuration's tooling comparatively limited.
Pros and Cons of the Options¶
Azure App Configuration (Feature Management)¶
A fully managed Azure PaaS service with built-in feature flag support via the Microsoft Feature Management library.
- Good, because it is a managed service with 99.9% SLA and zero infrastructure overhead for teams.
- Good, because Entra ID integration, audit logs, and Microsoft compliance certifications are included out of the box.
- Good, because a Terraform provider exists, supporting infrastructure-as-code provisioning consistent with Forge standards.
- Good, because it is already in use at SAIF for application configuration — extending it for feature flags requires no new vendor onboarding.
- Good, because estimated cost for 100 services is $40–75/month ($480–900/year).
- Bad, because it is Azure-native and not purpose-built for multi-cloud or on-premises deployments.
- Bad, because the feature flag management UI is less polished than dedicated feature flag platforms.
LaunchDarkly¶
An enterprise-grade SaaS feature flag platform with sophisticated targeting, experimentation, and change approval workflows.
- Good, because it offers industry-leading A/B testing, flag dependency analysis, and change approval workflows.
- Good, because it has broad SDK support (20+ languages) and strong compliance certifications (SOC2, HIPAA, GDPR).
- Good, because its non-developer-accessible targeting UI reduces reliance on engineering for flag management.
- Bad, because it costs $1,200–5,000+/month for 100 services ($14,400–60,000+/year) — 15–30× more expensive than Azure App Configuration at our scale.
- Bad, because per-service-connection pricing scales poorly for microservices architectures.
- Bad, because it is SaaS-only with no self-hosted option, adding a new external vendor dependency.
- Bad, because the operational complexity and feature set exceed current SAIF requirements.
GrowthBook (Cloud or Self-Hosted)¶
An open-source feature flag and A/B testing platform with cloud and self-hosted deployment options. One team at SAIF currently runs GrowthBook self-hosted on AWS.
- Good, because it is open-source with a free self-hosted option and cost-effective cloud pricing.
- Good, because it has strong A/B testing and statistical experimentation capabilities.
- Good, because it has SDKs for .NET and TypeScript.
- Good, because an existing SAIF deployment provides some organizational familiarity.
- Bad, because the existing SAIF deployment is isolated to one team on AWS and is not standardized across the organization, creating fragmentation risk.
- Bad, because GrowthBook Cloud costs $800–2,000/month for 20–50 users — 10–20× more than Azure App Configuration.
- Bad, because self-hosted deployment introduces operational overhead (provisioning, monitoring, upgrades) inconsistent with Forge's managed service preference.
- Bad, because advanced features such as SSO/SAML, audit logs, and premium support require a paid Pro or Enterprise license even for self-hosted deployments, negating the "free" cost advantage for an organization of SAIF's size.
- Bad, because it has limited native Azure integration; the current deployment is AWS-based.
Unleash (Cloud or Self-Hosted)¶
An open-source feature flag platform with cloud and self-hosted options and good targeting capabilities.
- Good, because the self-hosted option eliminates subscription costs.
- Good, because it supports user segments and gradual rollouts.
- Bad, because self-hosted operation requires infrastructure provisioning, maintenance, and upgrade management — inconsistent with Forge's managed service preference.
- Bad, because Unleash Enterprise Cloud costs $375–3,750/month for 5–50 seats, remaining 10–75× more expensive than Azure App Configuration.
- Bad, because its .NET SDK is less mature than Microsoft's Feature Management library.
- Bad, because it introduces a new vendor relationship with no existing SAIF footprint.
Build a Custom Feature Flag System¶
Develop an in-house feature flag service tailored to SAIF requirements.
- Good, because it provides full control over feature set and no vendor lock-in.
- Good, because it avoids licensing costs.
- Bad, because it requires months of engineering investment that is better directed at business value.
- Bad, because it creates an ongoing maintenance burden (security patches, scaling, reliability).
- Bad, because feature flag infrastructure is not a core SAIF competency; managed services provide better ROI.
- Bad, because estimated engineering cost is $24,000–60,000/year in opportunity cost.
No Change¶
Maintain the status quo of ad hoc per-team feature management without a platform standard.
- Bad, because applications cannot achieve same-day deployment goals without controlled rollout mechanisms.
- Bad, because there is no consistent way to reduce deployment risk or perform instant rollbacks across services.
- Bad, because feature flag implementations diverge across teams, increasing cognitive load and reducing platform predictability.
More Information¶
Cost Comparison (100 Backend Services, 20–50 Developers)¶
| Provider | Pricing Model | Est. Monthly Cost | Annual Cost |
|---|---|---|---|
| Azure App Configuration | $1.20/day/store + $0.06/10k requests | $40–75 | $480–900 |
| LaunchDarkly Foundation | $12/service connection + $10/1k MAU | $1,200+ | $14,400+ |
| LaunchDarkly Enterprise | Custom annual contract | $2,500–5,000+ | $30,000–60,000+ |
| GrowthBook Pro (Cloud) | $40/user/month (up to 50 users) | $800–2,000 | $9,600–24,000 |
| GrowthBook Self-Hosted | Free (basic) or Pro license ($20/mo) + AWS infrastructure; SSO/SAML requires paid plan | $150–400 + ops + license | $1,800–4,800+ |
| Unleash Enterprise (Cloud) | $75/seat/month (5-seat minimum) | $375–3,750 | $4,500–45,000 |
| Unleash Self-Hosted | Infrastructure + operational overhead | $200–500 + ops | $2,400–6,000 |
| Build Custom | Engineering time + infrastructure | $2,000–5,000 + ops | $24,000–60,000 |
Assumptions: 100 backend services polling every 30 seconds, minimal client-side usage, 20–50 active developer seats.
Multi-Cloud and Portability¶
Azure App Configuration is optimized for Azure-hosted applications. As SAIF's multi-cloud footprint expands:
- Short-term: Applications deployed to other cloud providers (AWS, Google Cloud) use the feature flag system native to that cloud provider (e.g., AWS AppConfig, Google Cloud Runtime Configuration) to minimize cross-cloud complexity and latency.
- Long-term: Assess the organizational split between cloud providers and evaluate whether to adopt a centralized, cloud-agnostic provider (LaunchDarkly or GrowthBook Cloud) or integrate a feature flag system directly into the Forge platform. This decision will be made once multi-cloud adoption patterns are clearer.
The cost savings of ~$1,150+/month versus LaunchDarkly provide budget headroom to migrate to a different provider or implement a platform-native solution should strategic requirements suggest it is necessary.
References¶
- Microsoft Learn: .NET Feature Management — Official Microsoft documentation
- Azure App Configuration Experimentation — A/B testing and feature experiments
- Unleash: Feature Flag Tools Comparison — Provider comparison
- GrowthBook Documentation — Open-source feature flags and A/B testing platform
- OpenFeature — CNCF vendor-neutral feature flag standard and abstraction layer
- PROP0007 — Feature Flag Standard (see standard document for implementation guidance)