Replacing a Custom Feature Flag Platform at Solaris: GitOps, Data Residency and OpenFeature
We are happy to welcome Olivier Laviale as a guest contributor to the GO Feature Flag blog.
Olivier led the initiative to replace the in-house feature flag platform at Solaris SE, a German Banking-as-a-Service provider. Below, he walks through the constraints that shaped the search, the seven tools he weighed, and why the team landed on GO Feature Flag — including the rough edges he hit and fixed on the way in.
Separating deployment from release is basic hygiene for a modern engineering organisation. For a Banking-as-a-Service provider, it stops being hygiene and becomes a requirement: when a new feature does not behave the way it was supposed to, we need to switch it off immediately, not schedule a rollback.
Our in-house feature flag solution served us well for a long time. It was straightforward, it did what it was built to do, and for basic on/off features it was entirely adequate. What it was not was something that could grow with us. This is the story of how we chose its replacement.
A quick primer, for anyone who needs it
If you already live in flag tooling, skip ahead.
Before feature flags, a bad bug meant rolling back the entire deployment. On a large monolith, that is not a button you press — it is a process, and it can take hours while the problem stays live in production.
A feature flag turns that into a switch. You toggle functionality in production, instantly, with no redeployment. That is the whole idea, and everything else is refinement on top of it.