🎯 Why Feature Flags? The “Why” before the “How”
Before diving into how we built our feature flag system, let’s talk about why we needed one in the first place.
At Infomaniak, we deploy code multiple times a day sometimes dozens of times. Our teams are autonomous, fast-moving, and focused on delivering value to our customers. But speed alone isn’t enough we also need safety, control, and observability.
That’s where feature flags come in.
What Are Feature Flags?
Feature flags are conditional switches in your code that allow you to turn features on or off without deploying new code. Think of them like circuit breakers for your software: you can enable a new checkout flow for 10% of users, disable a buggy module in production, or roll back a feature instantly all without touching the deployment pipeline.
Why We Need Them
1. Decouple Deployment from Release
You can deploy code to production without exposing it to users. This means your release cadence is no longer tied to your deployment cadence and you can ship faster, with less risk.
2. Safe Rollouts & Gradual Releases
Launch a feature to 1% of users, then 10%, then 100%. Monitor metrics, collect feedback, and roll back if something goes wrong all while keeping your users safe.
3. A/B Testing & Experimentation
Compare two versions of a feature (e.g., different UIs, pricing models, or checkout flows) and measure which performs better all within the same codebase.
4. Kill Switches for Emergencies
If a feature causes performance issues, crashes, or security problems flip a switch and disable it instantly. No need to wait for a hotfix deployment.
5. Enable Team Autonomy
Frontend, backend, and product teams can work independently they can merge their code, test in production, and release on their own schedule without blocking each other.
6. Reduce Risk in Complex Deployments
Rolling out changes across microservices? Use flags to control behavior per service, region, or user segment without having to coordinate deployments.
The Cost of Not Having Feature Flags
Without them, you’re stuck with:
- Big releases → high risk, high stress
- Long release cycles → slow feedback, missed opportunities
- No way to test in production safely → more bugs in production
- Manual rollbacks → slow, error-prone, stressful
In short: feature flags aren’t a luxury they’re a necessity for modern, scalable software development.
The Challenge: Choosing the Right Foundation
As our platform grew, we realized we needed more than just a “flagging tool” we needed a standardized, scalable, and future-proof system that could grow with us.
We evaluated:
- Flagsmith open source, but limited ecosystem
- Unleash great self-hosted option and integrated in our Gitlab Platform, but not standardised at the time
- Custom-built flexible, but high maintenance cost
Then we discovered OpenFeature.
Why OpenFeature Won
OpenFeature is not a service it’s an open standard for feature flagging. Think of it like OpenTelemetry for observability: a spec, not a product. It defines interfaces, SDKs, and provider integrations letting you plug in any backend (or even build your own) without rewriting application code.
Here’s why it won us over:
- Vendor Agnostic by Design
We didn’t want to be locked into one vendor’s pricing, UI, or API. With OpenFeature, we can switch providers (or run our own) without touching our application code. Today we might use Flagd as our provider tomorrow, we could switch to Unleash or even a custom in-house system.
- Polyglot Support
Our stack includes PHP, Go, Python, Node.js, and more. OpenFeature has official SDKs for all of them and they all speak the same language. Teams can adopt the same patterns, regardless of the language they’re using.
- Extensible Architecture
OpenFeature’s provider model lets us integrate with any feature flag backend. We started with flagd, but we’re already experimenting with other providers for internal flags all while keeping the same API in our apps.
- Community & Ecosystem
OpenFeature is backed by the Cloud Native Computing Foundation (CNCF) and supported by major players like Atlassian, LaunchDarkly, and Split. This means it’s not going anywhere and it’s constantly evolving with the community’s needs.
- Future-Proofing
As we scale, we want to avoid tech debt. OpenFeature gives us a stable abstraction layer. Whether we’re adding new services, adopting new languages, or integrating with CI/CD pipelines
OpenFeature adapts with us.
- Easy to deploy
Deployment is a breeze especially with the OpenFeature Operator.
Built and maintained under the CNCF, the OpenFeature Operator lets you declaratively manage feature flag providers and SDK configurations across your Kubernetes clusters — using familiar YAML manifests and GitOps workflows.
Implementation at Infomaniak
We started by:
- Standardizing on OpenFeature SDKs across our core services.
- Integrating Flagd as our first provider the reference implementation built and maintained by the OpenFeature team to ensure alignment with the standard from day one.
- Deploying OpenFeature Operator by default on every Kubernetes cluster
- Building internal tooling around flag metadata, Opentelemetry, and specific Framework SDK (Laravel for example).
- Training teams on the OpenFeature API and best practices with presentations and sharing feedback about implementations in teams.
The result? Teams are now shipping with flags more confidently, and we’ve eliminated inconsistencies across services. Plus, we’ve already saved time by avoiding vendor lock-in and we’re ready to evolve as our needs change.
What’s Next?
We’re exploring:
- Integrating OpenFeature with our internal proxies for dynamic routing based on flag evaluation.
- Adding OpenFeature to our onboarding templates so every new service starts flag-ready.
Final Thoughts
Choosing OpenFeature wasn’t just about picking a tool it was about choosing a philosophy: standardization, flexibility, and freedom.
At Infomaniak, we believe in building systems that empower teams not constrain them. OpenFeature gives us the foundation to do just that.
If you’re evaluating feature flagging systems, I encourage you to look beyond the vendors look at the standard. Because in the long run, the right abstraction layer will save you more time, money, and headaches than any single product ever could.
Enjoy the read. This article was written by Léopold Jacquot, Principal Engineer at Infomaniak. If you’d like to connect or follow my work, you can find me on GitHub or LinkedIn.