In many Belgian public institutions, continuous deployment is technically possible, yet releases stay rare. The reason is rarely the pipeline. It is the fear of exposing a feature to users before it is ready. When shipping code and switching it on are the same act, every release carries a risk that has nothing to do with the code.
We worked with a large Belgian federal public institution to separate those two acts: deploy code continuously, decide separately when to activate it. The lever was feature flags, adopted progressively rather than mandated. Today, 15 of its 17 technical teams use them in production.
The starting point
The institution already had a modern CI/CD foundation. The blocker was operational: how do you deploy several times a day without exposing features that are unfinished or unstable? The scope was 17 technical teams, several thousand agents downstream, and a Java / Angular platform on OpenShift.
The same problems came up at every release. Teams hesitated to deploy for fear of exposing unfinished code. There was no way to test a feature with a subset of users first, no central view of what was in progress, and no safety net to practice trunk-based development. Deployment and release were still welded together.
What we did
Rather than roll a tool out to 17 teams at once, we started with one pilot team, the free version, and time. The pilot put feature flags to work in production, gathered results, then shared them internally. Other teams asked for the tool instead of receiving it from above.
Concretely:
- Flagsmith, selected against a clear grid: conformity with the OpenFeature standard (no vendor lock-in), native fit with the Java / Angular stack, and deployability inside the client’s OpenShift.
- A proof of concept in production on the free version from July 2022, followed by the enterprise version in the client’s OpenShift in January 2025, once demand was real.
- SSO through the existing Keycloak, with no parallel identity to manage.
- Centralized governance: one unified view of who activates what, for whom, and when.
Code now ships to production continuously. Activation happens when a feature is ready, for the users it is meant for, and can be switched off at once if something goes wrong.
The numbers
| 88% | ~2 years | Deploy ≠ activate |
|---|---|---|
| of the teams (15 of 17) run feature flags in production. | for adoption to spread from a single pilot team, with no top-down plan. | deployment and activation are now two separate decisions. |
These figures belong to a specific project in a specific context.
What made the difference
Not the tool, but how it arrived. We built on what teams already used, the open standard, the existing stack, the Keycloak in place, so there was nothing to relearn and none of the usual resistance. Adoption grew by proof: the pilot showed the value, the rest asked to follow. The clearest sign is the move from the free version to the paid enterprise version on the client’s own infrastructure. Teams do not pay to keep a tool they were only tolerating.
That is why we speak of transition rather than transformation: a gradual movement anchored in each organization’s reality, not a switch you flip. The approach fits where a CI/CD base is already in place and leadership is willing to let adoption grow by proof. Where it is not, you adapt.
Going further
This project is part of our IT Mission approach, alongside L4F (application portfolio analysis and steering through AI) and organizational transition. 5th floor has partnered the digital work of Belgian public institutions since 2017, and has been B Corp certified since 2025.
If releases feel risky, or your cadence is held back by the fear of exposing too early, get in touch. A one-hour conversation is often enough to map the first steps.
