DevOps, Teams and Architecture

Move Fast, Break Nothing*: Feature Flags as Enabler of Continuous Deployment

Jan Švejda — Sun, 25 Jan 2026 14:16:08 GMT

The Conflict of Speed vs. Stability

If there are axioms in software development, then the duality of users wanting more features and a bug-free, always-available system must be one of them. An unstable system is the quickest way to churn users, but without features, you are bound to get disrupted by innovative competitors. So, there is no way around it: you have to release changes. The trick is ensuring these changes have the desired effect and are well-accepted by users. And challenging things? Those require a strategy.

In our case, we fight for market share with companies sometimes 10x bigger than us. Instead of shying away, we turn this into a competitive advantage because we can do things differently. We can adapt and align the whole organization on a new vision much more quickly. To strengthen this edge, we decided to use Continuous Deployment (CD) for all changes to our product, a B2B SaaS platform for process digitalization.

The premise of CD, as you might read on social media or in explanatory videos, is usually this:

Code a new change.
Run automated checks.
Once passing, deploy the new version to production.

This sounds like the antithesis of stability. As with any design, product, or even art, the first version of anything new requires feedback and rework to stand the test of its beholders.

So you say: “We should deploy the first version directly to all users?!”

The answer is no, you should not. You should have a strong release process leveraging feature flags to decouple a release from deployment. And just as importantly, you should align this process with your documentation, marketing, and customer communication. You will understand how to adopt the 5 segment release process after reading this article.

Why We Use Feature Flags

Feature flags allow us to get features into production and into the hands of Product Owners, Presales, and early adopters without disrupting other users. We can iterate rapidly, testing and gathering feedback in the same production environment our users live in every day. We do this without a new version, everything is on main. This offers three major advantages:

Feedback without High Complexity: Users can test features early, yet we have no maintenance of extra environments since we always keeping only a single version up and running.
Minimized Risk: We can deploy multiple small changes instead of big bang deployments, which reduces risk exposure and emphasizes steady flow of work within the organization.
Release Control: The teams decide on their own when a feature is ready. They own their flags and the entire release process. They update documentation and set release dates without the pressure of a deadline because releasing a feature is just a single boolean configuration.

Both our frontend and backend components are integrated with Flipt, a flag management tool. With a single boolean configuration, we manage the narrative and control exactly when a feature appears to users with a single boolean configuration. It also puts an end to the "Has this been enabled in environment X?" questions; the flag state tells the story.

Feature flags vs. Tiers - it is important to distinguish flags from product tiers. Flags play their role strictly in release control, not for long-term configuration of customer licensing, contractual agreements or usage based pricing. Flags have to be removed not long after a feature has been released as the codebase would otherwise get littered with if-else statements.

Feature Flag Lifecycle and the Five User Segments

To manage risk effectively, you cannot just "flip a switch" and be done with it. That would destroy the whole purpose of having control. We found using a ring-based deployment model in expanding user segments works well. Progressively, as a change matures, you enlarge the subset of users who see it. In other words, you limit the initial blast radius, gather data and feedback and only expand once certain of the stability and value of the change. Think of it as a funnel that gets bigger and bigger as the feature matures:

Your mileage may vary, but we found it effective for a feature to go through five consecutive segments. These build up on each other as every segment includes all users in the previous segments:

Development

The moment code is merged, it’s live in the development segment. This includes the developer environments and select internal environments used for testing and training. Here, the goal is immediate feedback for the developers themselves. It’s about seeing the code run in a safe environment without impact if anything goes sideways.

Validation

A feature moves to validation once it has been presented in a Sprint Review and the Product Owner has given the green light. Any bugs found during the initial dev phase must be resolved here. This is where you ensure the feature actually does what it was intended to do. The validation segment includes all internal testing and training environments.

Preview

Next, promote to preview. This opens the feature to select non-live tenants in production used for demos and manual or automated tests in production. This is a crucial step - it is now enabled on production infrastructure with production-like data, but without the risk of impacting a customer’s daily operations.

Release Candidate

Before a full release, we enter the release-candidate segment. This is the first time a change faces users who use the product for actual work. In our case, we use our own internal environments used by the whole company or a department. It’s the final "smoke test" to ensure that everything holds up under real-life usage and should happen a few days in advance of a release.

Release

Finally, a change reaches the release segment. It is enabled for all tenants in production. But even here, the work isn't "finished." You should keep the toggle active for a short period - this acts as an emergency brake. If something unexpected happens at scale, you can roll back the feature almost instantly without having to redeploy the entire application.

The below diagram depicts the 5 segments:

After all these segments, the feature flag is removed from the application code, including obsolete code and finally, the feature flag is removed as well. It is vital to remove the flag only after you do it in the application code. Otherwise, you will effectively disable the feature for all users.

Communication During the Lifecycle

A feature flag strategy is 50% technical and 50% communication. With changes, users expect information how these improve and impact their ways of using the software. This is not always necessary, many changes are self-explanatory and do what users expect. Nonetheless, more complex features require documentation and, even more so, breaking changes require clear explanation and instructions. Whatever the information and its form, timing is crucial. The effort you put into sending information or updating documentation will be lost, if you inform users about a new feature after it had been already deployed.

On the other hand, if you are informing ahead that you are about to release something new, then users expect to know when this happens - so you have to commit to a date. What if you don’t make it though? What if you must take care of multiple incidents in the meantime or your build infrastructure does not cooperate? All this can happen if your release process is complicated. Your final act of releasing should therefore be trivial to limit the amount of things that can break. We made it so, that releasing a feature is a single flip of a boolean. Like this, the risk of not meeting a communicated release date is minimal.

Furthermore, internal users and stakeholders will want to know about work in progress. The 5 segment strategy therefore guides when and how to provide information during each of the segments:

Development: Here communication is purely internal and within the team or closest stakeholders.
Validation: First tests have been successful so ask for feedback early. Provide an overview using mockups, slides or first working versions, e.g., in a Sprint Review, or live demos. Ask internal users to test and provide feedback.
Preview: Now that the feature has taken shape you should show the intention of releasing it. Update any "Coming Soon" section in docs, ask for final tests and make sure people outside your team use it. Release first versions of the documentation around internally and improve based on input.
Release Candidate/Release: Your feature is ready to step into the limelight. Update the official Changelog and documentation (either in app or separate). Make broad announcements using email, notifications or similar channels. Explain in a webinar or workshop. The particular communication strategy differs between features, but Changelog is the minimum.

A successful release strategy is 50% technical and 50% communication. Users expect to understand how changes will improve or impact their workflow. While many updates are self-explanatory, complex features require documentation, and breaking changes demand clear explanations and instructions.

Regardless of the format, timing is crucial. The effort spent on communication or documentation is wasted if users are frustrated by a new feature that has already appeared in their environment.

Managing Expectations and Risks

If you inform users ahead of time that a release is coming, you must commit to a date. However, real-world obstacles—like high-priority incidents or infrastructure failures—can jeopardize those commitments. To mitigate this, the act of "releasing" must be trivial. By utilizing feature flags, we have ensured that releasing a feature is as simple as flipping a boolean. This minimizes the risk of missing a communicated release date due to deployment complexities.

The 5-Segment Communication Strategy

Stakeholders and internal users need visibility into work-in-progress. Our five-segment strategy guides how and when to provide information:

Development: Communication remains internal to the team and immediate stakeholders.
Validation: Once initial tests succeed, seek early feedback. Provide overviews via mockups, slides, or early working versions (e.g., during Sprint Reviews or live demos). Encourage internal users to test and provide input.
Preview: As the feature takes its final shape, signal the intent to release. Update "Coming Soon" documentation, request final testing from users outside the core team, and refine internal documentation based on their feedback.
Release Candidate & Release: Your feature is ready for the limelight. Update the official Changelog and external documentation. Use broad channels - such as email, in-app notifications, or webinars - to accompany the rollout. Communicate ahead or together with the release. While the specific strategy varies by feature, an entry in the Changelog is the minimum requirement. Important: Don’t skip the release candidate segment, we have had cases of critical bugs being found a day before planned rollout.

Managing Complexity

Feature flags do not come free. You need to branch at the appropriate places in code to ensure your unfinished changes do not leak. That can get out of hand quickly without a plan. If you are dealing with quantities of unreleased features, this strategy is likely not for you. Too many flags is deadly both for codebases and velocity, they must be short-lived. Removing a flag should be included in the definition of done for features, but you also need to ensure there are not too many features in progress to begin with.

If you are already at the point of having too many flags, a viable strategy is to allow adding a new feature flag only if two existing ones have been removed. This way you pay off technical debt gradually.

Another problem is if flags in your flag management tool drift away from the codebase. Then you have to go through each and every one to resolve the issue. There is a better way though - let the compiler do the work! Instead of:

if (featureState["fresh-design"]?.enabled || false) {
  // new logic
} else {
  ...
}

Generate an enum from flag definitions. You will get compilation errors unless the flag exists:

// start generated
enum class BoolFeatureFlags(val key: String) {
    FRESH_DESIGN("fresh-design"),
    V2_API("v2-api"),
    ...
}
// end generated

if (featureState.enabled(FRESH_DESIGN)) {
  // new logic
} else {
  ...
}

The workflow then looks something like this:

Each flag management tool has a different format, so your mileage may vary, but a simple script will do the job. That way, you prevent different sets of feature flags. If you want to go the extra mile, an idea courtesy of Marc, is to have the code generator skip flags that are marked as deprecated, e.g., with a description prefix [DEPRECATED]. Then you can very safely remove flags like so:

Add [DEPRECATED] to description in the flag management tool. This triggers compiler errors in all places the flag is used.
Update code to remove unneeded logic.
Deploy the application.
Then delete the flag from the management tool.

With this in place, your codebase won’t suffer.

Conclusion

Segmenting your users in up to five categories and consecutively enabling new changes one by one in each using feature flags gives you full control over the feature release process. By adhering to this rollout strategy, our team achieves:

Higher and fully automated deployment frequency using Continuous Deployment.
Lower failure rate. Bugs are caught in early segments.
Better product-market fit. Features get very early feedback, even from customers.

The trade-off for this strategy lies in higher code complexity. It is, however, well-manageable if you 1) focus on finishing features, 2) define a clear feature flag lifecycle, and 3) deeply integrate feature flag management with your codebase.

Let me know if you try or adapt this blueprint to your needs, looking forward to your thoughts!

User-managed feature flags with Flipt - Part 1

Jan Švejda — Tue, 08 Apr 2025 19:30:04 GMT

Once a business takes continuous deployment seriously, it may reach a point where separating the release and deployment process starts to present a real blocker. If done well though, this can be an enabler for higher performance. Some might go as far as to consider this separation a prerequisite for deploying continuously. For example, if you have aligned schedules with the rest of the business, you typically cannot launch a feature immediately after development finishes, but would have synchronize, hampering any other work you need to do. Furthermore, if you have the luck of having feature-hungry power users, you will find that letting them beta test features allows for a faster feedback loop and helps you deliver more value for all users.

In this article, we will take a look into:

Configuring a Docker image for Flipt with local data.
Integrating Flipt into your GitOps practices.
Letting users manage a subset of the flags on their own.

Feature flags, toggles, switches… which one is it?

There can be a certain confusion sometimes regarding each of these terms. Let us briefly summarize the meaning of each.

A feature flag is the most generic of these - it is a configuration item that lets you configure a feature in a specific environment. This does not have to be a boolean, but also a string, an integer etc. It allows fine control on how the feature works allowing you to test the feature beforehand.
Feature toggles, on the other hand, are simpler and are typically limited to boolean values on/off. Depending on your needs, this may control features per environment, tenant or user.
Feature switches are synonymous with feature toggles. Sparingly, they may refer to toggles which have a contractual binding to them. So, if a user does not pay for feature X, then the appropriate feature switch for this user would be off.

Flipt, open-source feature flagging

Before you go and implement your own feature flagging solution, it is worthwhile to research what is out there so that you focus on what is important and ideally have room to grow if you need more functionality, analytics, or integrations. This is where Flipt comes in as it represents one of the most popular open-source choices for feature flagging. Crucially, it integrates with OpenFeature, a standard steadily rising in popularity that provides an SDK to integrate feature flagging tools into your code. Flipt has both a worry-free cloud version and a full-featured self-hosted one. In this article, we will look into how the latter can be integrated into a microservice-oriented platform architecture. Have a look at a short example from Flipt’s homepage how you can use it to resolve if a feature “New UI” is enabled:

// Configure OpenFeature to use your Flipt instance
OpenFeatureAPI.getInstance().setProviderAndWait("sync", fliptProvider);
var client = OpenFeatureAPI.getInstance().getClient("sync");

// Prepare information to send with the flag evaluation request
var evaluationContext = new MutableContext();
evaluationContext.setTargetingKey("user-123");

// Evaluate if feature "New UI" is enabled by resolving the appropriate flag
var value = fliptProvider.getBooleanEvaluation("new-ui-enabled", false, evaluationContext).getValue());

Using Flipt as the core of your feature flagging strategy

To show how Flipt can be integrated, we shall make several assumptions about the architecture which will guide the solution.

Multiple development teams - your organization consists of multiple development teams each being responsible for a subset of the services which make up your application.
Multiple source code repositories and development teams - teams in your organization have dedicated Git repositories, there is no monorepo.
Multi-tenancy - your applications are multi-tenant, meaning you have only one production environment, but each customer has dedicated data space in your application, which only the users for that customer have access to.
Tenant admins can manage toggles - each tenant has admin users which can enable or disable features, giving them the possibility to preview these early on.
Containerization - you want to host Flipt yourself and can run containers in your environment, be it a cloud or on-premise environment. Flipt supports many other kinds of self-hosted operations. Take a look in the docs.

With that out of the way, let’s dive right into it!

Configuration

Flipt can store feature flag configuration using multiple backends including relational databases, object storage, git and more. There lies beauty in simplicity though, so let’s take advantage of using YAML files as the source. I will explain later in section Flipt and GitOps how this helps developers change and keep track of things.

With that said, initiate a new Git repository or if you prefer, add a subfolder to your monorepo.

├── README.md
└── src
    ├── config.yml
    ├── Dockerfile
    ├── features
    │   ├── features.yml
    │   └── project-x.features.yml
    └── test
        └── rest
            └── evaluate.http

Under src, we will keep the actual configuration, such as the Dockerfile and feature flags. From the top of the src folder, we have:

config.yml - Flipt configuration, see the documentation for all available options.
Dockerfile - we build an image that, immediately after starting, will be ready to evaluate current feature flags.
features - folder containing all the feature flag configuration files. Here you can place files containing your desired set of feature flags in their particular namespace. This is where teams would go update their flags which are currently available in their application.

Let’s have a look at each of these items in more detail.

Side note - build system