When it comes to feature flags, teams with 5-20 engineers face similar challenges to teams with hundreds of developers. What you never want is one engineer flipping a feature toggle to unintentionally affect the work of another engineer.
This is a conceptual problem with feature flags. It doesn't matter if you are using an open-source feature flag tool, or a feature flag service. Let's see best practices ConfigCat recommends.
1 Developer = 1 Environment
This is the best practice if you have a small number of engineers working heavily parallel on the same component.
Simply create a separate ConfigCat Environment for each developers.
In this example, Jane and John have their own dedicated ConfigCat Environments. This allows John to disable "Show Extra Levels" for himself while not affecting the feature flag's value in Jane's environment. At the same time, they as a development team still have their LIVE, and STAGE environments.
This approach requires that your feature flag service supports Environments.
While it works well for small, and agile teams, creating a dedicated environment for each developer is inconvenient if you have too many developers.
1 Developer = 1 Targeting Rule
The best practice for large teams is to use Targeting to set different feature flag values for their developers. Simply add two new Targeting Rules to your feature flag and use Comparison to match a certain developer. You do not need to create separate Environments for your developers. Just have the usual ones, like DEV, STAGE, and LIVE.
In this example, both John and Jane work in their team's DEV environment. They use their machines' name to set the feature flag's value for themselves without impacting each other's, or their team's flag values.
Both 1 Developer = 1 Environment, and 1 Developer = 1 Targeting Rule work well. It does not matter if your team usesReact,Swift, orAndroidfeature flags (or any other). What matters is your team size. ConfigCat recommends _1 Developer = 1 Environment_ for small teams, and _1 Developer = 1 Targeting Rule_ for large teams.
BTW we have mentioned Swift, and Android for a reason. Adding a feature-flag to your mobile application is a very good idea for multiple reasons - but the most important is the relative cost of being able to remotely reconfigure a mobile app compared to distributing a modified version of that app to your users.