In modern software engineering, separating deployment (shipping code) from release (enabling features) is a powerful practice. For a Banking-as-a-Service provider like Solaris, this isn't just about convenience: it's essential for mitigating risk, staying compliant, and maintaining engineering speed.
As we scaled, our homegrown toggle system began to hit its limits. This is the story of how I led the search for a new feature flag solution and how we eventually landed on the right fit for the company.
What's a feature flag?
Before feature flags, when a bug was found on production, you had to quickly revert to a previous version to fix the issue. The process could take several hours for large monolithic applications. Feature flags are configuration switches that let you turn functionality on or off in production without a new deployment. The toggle is relatively immediate.
The Problem: Outgrowing "On/Off"
Initially, Solaris relied on a simple database-backed toggle system. It served us well in the early days, but as our ecosystem grew, so did our requirements. We couldn't enable a feature for just one partner, a small group of developers, or a specific country. It was always "all or nothing." This became a major bottleneck for our speed and our ability to manage risk.
Beyond simple on/off switches, we wanted to move toward data-driven decisions through A/B testing, measuring the impact of changes before committing to a full rollout.
The Evaluation Framework: Four Non-Negotiable Pillars
The feature flag market is crowded. To find the right fit, I established four pillars that served as our "North Star" during the evaluation of tools like LaunchDarkly, Optimizely, Split.io, Flagsmith, Unleash, GrowthBook, and Flipt.
1. Security & Sovereignty (The Banking Constraint)
In the German market, data residency is the foundation of trust; it is a regulatory mandate, not a suggestion. Operating within one of the world's most stringent regulatory environments, we must ensure that our customers' financial footprints remain within the legal borders of the Federal Republic or, at the very least, the European Union.
This constraint immediately sidelined many "SaaS-only" providers. Their inability to guarantee that sensitive configuration data and user context would remain within our controlled infrastructure presented an unacceptable compliance risk. For a German FinTech, maintaining total sovereignty over the evaluation engine isn't just about security, it's a prerequisite for our license to operate.
2. Budgetary Pragmatism
I initially had a zero-budget mandate for external tooling. This excluded "premium enterprise" platforms like LaunchDarkly, Split.io, or Optimizely, which, while excellent, often come with enterprise price tags we couldn't afford.
3. GitOps as a First-Class Citizen
We wanted our flags to live in code, not just in a hidden database. By treating Configuration as Code, flags benefit from the same pull request reviews, version history, and audit trails as our core banking logic.
4. Interoperability via OpenFeature
To avoid vendor lock-in, I insisted on a solution compatible with OpenFeature. OpenFeature provides a vendor-agnostic SDK standard. By implementing this, we ensured that if we ever migrate providers, we only change the underlying configuration—not our application code.
The Winner: GO Feature Flag
Here is how the contenders stacked up against our specific needs:
| Solution | Strength | Why it didn't fit (at the time) |
|---|---|---|
| LaunchDarkly, Split, Optimizely | Feature-rich, best UI | High cost; SaaS-first approach conflicted with our strict data sovereignty. |
| Unleash, Flagsmith | Robust, Open Source | Required managing additional databases and infrastructure overhead. |
| GrowthBook | Excellent for Analytics | Focused heavily on A/B testing; we needed a more DevOps-centric GitOps flow. |
| Flipt | High performance | At the time, the GitOps integration was less mature than our winner. |
After presenting my findings to the Principal Engineering group, GO Feature Flag emerged as the optimal choice for Solaris. It hit the sweet spot between power and simplicity.
-
GitOps Native: It requires no database. It uses a YAML file per environment, stored in a GitHub repository and deployed to its corresponding S3 bucket. It treats feature flags exactly like we treat our code and fits perfectly into our existing deployment pipelines.
-
Targeting Power: It supports complex rules, allowing us to target by user ID, region, or custom attributes.
-
Plug-and-Play Integrations: It fits right into our existing setup. It supports various "retrievers" (how it gets data from S3 or GitHub) and "exporters" (how it sends data to tools like Prometheus), so it worked with our observability stack from day one.
-
Open Source & Low Footprint: As a lightweight Go application delivered via Docker, it runs seamlessly on AWS Fargate with minimal resource consumption.
Friction and Contributions
Choosing an open-source tool often means becoming a partner in its development. During the Proof of Concept phase, I encountered several "rough edges" and decided to contribute back to the ecosystem as I went along.
I found that the documentation hadn't quite caught up with the tool's rapid growth: incorrect volume mapping in the Docker setup, a broken Ruby SDK example using import instead of require, and a JavaScript SDK example that failed silently because the provider wasn't awaited before flag evaluation.
I also filed several bug reports: a targetingKey mapping issue in the JavaScript SDK that caused targeting rules to silently fail, and a configuration bug that made it impossible to configure the app using environment variables alone—a must-have for our Fargate deployment.
Beyond fixes, I contributed a missing feature across three SDKs. Our security setup (WAF) blocks requests made without the User-Agent header. I added CustomHeaders support to the Go SDK, the JavaScript SDK, and the Swift SDK.
The maintainers were responsive, collaborative, and prompt to review and merge my changes. For an open source tool you're betting production infrastructure on, that matters. It made the whole experience genuinely enjoyable, and I was glad to receive an envelope full of stickers.
Driving Adoption at Solaris
A tool is only useful if people know how to use it. To ensure a smooth transition, I built reference implementations for every language in our stack—Go, Ruby, Java, Kotlin, Swift, and JavaScript. I then led several "Deep Dive" presentations for our Principal Engineering group and team champions, and held one-on-one office hours to help teams tackle the specific challenges in their own corners of the codebase.
Conclusion
By prioritizing OpenFeature and GitOps, we didn't just buy a tool; we built a sustainable workflow. Solaris now has the power to roll out features with surgical precision, keeping our banking platform stable while our developers move faster than ever.
If you are looking for a feature flag solution, look beyond the UI. Look at how it fits your deployment philosophy, your regulatory constraints, and your long-term independence.