Python feature flags guide: Everything you need to know

When it comes to adding feature flags to your Python app, you have several options. And given how feature flags help you manage your feature lifecycle better, they’re essential. In fact, as Forrester has found, feature management is already “hot” with dev teams, with 31% finding it to be “mission critical.”

Feature flags don’t just allow you to turn your Python app’s features on or off, but also help you implement DevOps practices like targeted releases; continuous integration, delivery, and deployment; and progressive delivery. Adding feature flags to your app helps customer service ops as well, as they support customer entitlement management. Finally, when done right, your Python feature flags can even empower your product and marketing teams, allowing them to orchestrate strategic growth strategies. 

These solutions don't just bring feature flagging and management to your DevOps mix, but also feature experimentation. Let's explore how feature experimentation solutions along with their alternatives work for adding feature flags to your Python application and how they compare.

Building your own Python feature flag solution

1. You start by defining features that you want to be able to turn on or off.
2. Next, create a configuration file or a table that holds the value telling if a particular feature needs to be on or off. This file implements at runtime, and depending on the value assigned to a feature, the feature is made available (or not). 
3. Editing the config file and changing the feature flag values modifies the app behavior in terms of the feature availability. This setup also requires you to build a simple admin panel for this part (so everyone can use it).

As you can tell, this is the most simple use of feature flags – a feature is either enabled for everyone at once or disabled for all.

With this simple setup, you can’t:

• Target users. A feature is either available to your entire user base or no one at all.
• Implement progressive delivery. You can’t progressively deliver features to reduce risk. It’s not possible to launch a feature first to just beta users, for instance. This would need a much more sophisticated system (which is possible to build but will be a huge development project for your team, taking bandwidth away from product development).
• Experiment with different variations of a feature. While this goes beyond feature flagging, you can’t use such a system to test different variations of a new feature or an improved existing feature and see how users respond to the different versions (and how they move your business KPIs).

Peter, a Stack Overflow member, shares frustrations his business ran into using its own in-house Python feature flag management system:

“Right now, we have our own solution implemented, which I regret very much. Initially, it seemed like a simple task to have downloadable config JSONs on a server containing the feature flag values, along with a minimalistic admin page for editing them. However, the complexity increased when we wanted to add exceptions, such as serving one value for one user group and another value for a different segment, also known as A/B testing. After attempting to integrate this feature into our current solution, we successfully convinced management to invest in a proper feature flag service."

As Peter underlines, it’s easy to start with feature flags by building an internal feature flagging system, but you can get boxed in it. Such a system can easily spiral out of control if you use a lot of feature flags, as scalability is a problem. An internal feature flagging solution also only caters to dev teams, whereas feature flags can be great tools even for the product and marketing teams. We’ve delved deeper into this in our article, DevOps Feature Flags: What Are They and How to Use Them. 

Let’s now talk about using third-party feature flagging solutions to add and manage Python feature flags in your application.

Using an open-source or proprietary Python feature flag solution

When it comes to third-party solutions, you have two options for adding feature flags to your Python app. You can either go the open-source route or choose a paid feature-flags-as-a-service solution.

With both options, you essentially get a Python SDK to add to your application. These SDKs contain basic coding for most of the feature flagging and management logistics you need. Once you integrate them into your app, you can build on it.

Also, with most open-source and proprietary solutions, you get three ways to implement your Python feature flags. You can: 

• Go with an on-premise or self-hosted implementation
• Use a hosted (cloud) service
• Choose a private cloud option

This choice depends on your organization’s data policies.
Let’s now zoom in on how both these types of Python feature flag solutions – open-source and proprietary – work.
Most DevOps teams are looking to save costs and pivot to open-source solutions, as they don’t come with any licensing fee. But while open-source Python feature flag solutions are free, they can be limiting.

Open-source feature flagging solutions are free, but with limitations. Open-source solutions might seem free (they are, at least to start with) but you can easily hit your free open-source plan’s limits. For instance, most open-source feature flagging solutions support just one user seat – so you can only give access to, say, your lead engineer. Alternatively, there could be a cap on the number of flag requests that your app can make. If you’re considering an open-source solution, you probably know such software’s fair usage policies. Now, it might sound feasible to pay some fee for boosting the request limit in this specific case, but, you’re still stuck with a single seat. At other times, it could be about your audience volume. The point is you’ll keep hitting limits, leading to inevitable upgrades.

This is a resource-intensive setup. While an open-source SDK will put you on a fast track to using feature flags in your DevOps processes, you’ll still need sizable development resources to build your flagging system. Ongoing maintenance and development costs, too, can add up fast. And we aren’t even talking about the effort required to build any integrations. 

Support is crucial. Another aspect to consider here is support. This one comes down to community support vs. dedicated support. If you use an open-source Python feature flagging solution, you’re mostly left to yourself if you run into issues as the only support channel open to you is forums. Another downside with open source solutions is that the vendor doesn’t need to have any service level agreements in place guaranteeing uptime or performance. Besides, when it comes to feature flagging, support isn’t just about resolving issues. Sometimes working with a support team (or more so, a customer success team) helps you expedite things, implement them better, and even optimize your feature/experience lifecycle. 

Navigating regulatory risks is another consideration. If you happen to work in a heavily regulated industry like healthcare or fintech, open-source solutions can put you at risk. For example, if you’re an HCO, you can’t use a free open-source feature flagging solution unless you can ensure compliance. You need a solution like Kameleoon that enters into an SLA with you that regulations like HIPAA mandate. 

In contrast, you won’t run into most of these issues with paid Python feature flag solutions. Most feature flags-as-a-service SaaS providers come with straightforward plans, offer support, and also meet regulatory requirements.

One limitation with such solutions is that most of them cater to just your DevOps team. So if you want to use your new or improved features or product experiences as a growth strategy, your marketing and product teams won’t be on board here. Also, the majority of such feature flagging solutions fail to offer mature feature experimentation capabilities, which can become a limitation once you’re ready for feature experimentation. Finally, data storage can still remain an issue. When evaluating a SaaS feature flagging solution, it’s important to see where your end-user data is stored to ensure regulatory compliance.

Let’s now discuss a third kind of feature flagging solution for Python apps. This one brings more than just feature flagging and management. It adds feature experimentation to the mix. 

Enabling feature flagging, management, and experimentation in Python apps with full-stack solutions

For product-led businesses, the role of feature flags has evolved beyond just feature on/off switches. Feature flags, for such organizations, are a crucial growth staple that DevOps, product, and marketing teams leverage to ship better product experiences safely, achieve product-led growth, and meet business KPIs.

A feature experimentation solution makes all this possible. By using a feature experimentation solution (that automatically includes some best-in-class feature flagging and management capabilities) for your Python app, you can keep shipping features – even if they’re unfinished. You can roll out your features progressively, launching them first to your QA team, followed by your beta users, and so forth. If you’re launching an improved feature, you could show it to, say, just 20% of your users and collect feedback on the improvement. You can also experiment with multiple variations of a feature to find the best one. 

Also, with feature experimentation, instead of fully developed features, you can ship high-quality prototypes and see how they impact your metrics before working on full-fledged versions. Feature experimentation also shows you your most impactful features and experiences, so you can spend more of your DevOps bandwidth on them. Essentially, feature experimentation helps you move toward hypothesis-driven development (and growth). You can measure new features and product experiences against growth metrics.

Finally, feature experimentation solutions help you orchestrate organization-wide growth experiments. Feature flagging and experimentation prove central in the transition to becoming a product-led organization. For instance, when we discovered that our high-value customers heavily relied on integrations, we realized we could emphasize integrations across the entire customer journey. Feature flagging and experimentation help test such hypotheses.

For example, we could use a painted door experiment to show a few “coming soon integrations,” and see which integration generated the most interest. (We actually did this.) We could then get our DevOps to work on a few integrations (prototypes). Our product and sales team could – again, using feature flags – enable beta access to such integrations to leads who expressed interest in trying them. We could also experiment with trying to sell each integration as an add-on and let businesses build their bespoke stacks. Alternatively, we could launch an extra tier which would unlock even more integrations.

Choosing the right feature flag solution for your Python app 

If you’re just starting with feature flags, building a simple in-house feature flagging solution might work fine.

If you’re exclusively interested in feature flagging and management to enable your DevOps teams to deliver speedier and safer releases, a feature flagging and management solution
can suffice.

However, if you’re looking to move toward hypothesis-driven development that ties directly to growth metrics, consider exploring full-stack feature flagging, management, and experimentation solutions like Kameleoon. Our own research shows that 90% of organizations actually prefer using a single experimentation solution that works for all their teams.

Request a demo to see how Kameleoon could become your organization-wide all-in-one
experimentation solution.