ConfigCat's Favorite Feature Flags and the Biggest Blunder in Feature Flag History

At ConfigCat, we use the best feature flag provider in the world. Plot twist: it's ConfigCat. We're basically in a committed relationship with ourselves. Some call it narcissism; we call it quality control.

In this article, we'll share real-world feature flag examples from production, explain how we use our own system inside ConfigCat, and confess the biggest feature flag mistake we've ever made (so you don't have to repeat it).

How to Use Feature Flags in Your Application?

At ConfigCat, we have a whopping number of 70 feature flags that control many different aspects of our applications on the backend and frontend sides as well.

We use feature flags to:

• Show targeted banners
• Hide in-progress features
• Run controlled experiments and A/B tests
• Roll out new features gradually
• Control beta access for selected users
• Separate behavior across environments (dev, staging, production)
• Flip emergency kill switches in production

In practice, this means we can ship code safely, test ideas without risk, and react instantly when production gets... interesting.

Let me show you some real-world examples of how a feature flag tool utilizes feature flags.

The Cute One - the isSantaHatVisible Feature Flag

During the holidays, we dress up our cute ConfigCat logo with a Santa hat on our login/signup pages.

Yes, there is a feature flag for that. Yes, it's mission-critical.

The code behind it is pretty simple yet so powerful. Instead of hardcoding dates, we check the current month and day and let configuration decide whether the hat appears.

readonly isSantaHatVisible = resource({
  loader: () => {
    const now = new Date();
    return this.configCatService.getValueAsync("isSantaHatVisible", false, { 
      identifier: "n/a", 
      custom: { 
        month: now.getUTCMonth() + 1, 
        day: now.getUTCDate()
      } 
    });
 },
});

The "Learning" One - comparatorSuggestionsForComparisonAttributes

This feature flag's key is the proof that naming things is still one of the hardest problems in computer science.

We strive to build an intuitive interface that anticipates what customers need, making their workflow seamless and frictionless.

ConfigCat's targeting rules offer powerful comparators to help you build precise rollout strategies. We launched with 15 comparators covering text, semantic versions, and numbers. Fast forward to today: we now have 35 different comparators available.

More choice is great, but it came with a cost. We didn't want our customers spending too much time scrolling through irrelevant options. The solution? Context-aware filtering. Now, when you're building targeting rules around registration dates, we automatically surface datetime comparators. Working with app versions? You'll see semantic version comparators front and center, not text-based ones you'd never use.

Behind the scenes, a feature flag powers this intelligence. It takes the comparison attribute you've selected and returns the most appropriate comparators. We could have hardcoded these mappings, but that would have meant redeploying every time we wanted to tweak the logic.

This is an important point: feature flags are not just for hiding unfinished features. They can power adaptive product behavior in production without increasing deployment risk.

Let us know if your comparison attributes are not showing the right comparators, and we'll try to adjust them.

The Guardian Angels - canUseConfigCat, isEmailSendingEnabled, disabledOrganizationCreation

Back in 2020, we launched our public Bug Bounty Program without DDoS or firewall protections in front of our infrastructure. Basically, we walked into a gunfight with a butter knife. It didn't take long to realize we needed emergency parachutes inside the codebase.

So we added operational safety switches.

Email spammers trying to bankrupt us via our email provider? We deployed the isEmailSendingEnabled feature flag faster than you can say "captcha". (Of course, we later added proper CAPTCHA and infrastructure-level protections like responsible adults.)

Tired of manually deleting the 26th fake registration of [email protected]? disabledOrganizationCreation became our new best friend.

Spotted someone clearly up to no good? Time for feature flag jail with canUseConfigCat. Sorry, not sorry.

Why does this matter?

These weren't "product" flags. They were operational kill switches. There's an important difference.

Every production system should have emergency controls that allow teams to:

• Disable high-risk subsystems instantly
• Limit abuse without redeploying
• Isolate suspicious accounts
• Protect infrastructure while investigations are ongoing

A deployment pipeline is not an incident-response mechanism. Feature flags, when designed properly, can act as one.

We've since added proper DDoS protection, firewall layers and abuse prevention mechanisms. But these switches remain as battle scars and as proof that runtime control can literally save your system when things go sideways.

The Biggest Blunder in Feature Flag History - maintenanceModeEnabled - AKA How Not to Use Feature Flags?

Let me tell you about the time ConfigCat, the feature flag service provider, spectacularly failed at using feature flags.

We had a major database migration scheduled and needed a simple way to lock out customers temporarily. Easy, right? We're the feature flag experts after all!

The plan was foolproof:

1. Create a maintenanceModeEnabled feature flag to be able to show a friendly "we'll be back soon" page. ✓
2. Turn on the feature flag. ✓
3. Execute the database migration. ✓ with flying colors.
4. Turn off the feature flag. ✗ Houston, we have a problem.

Turns out, when you enable a feature flag that blocks everyone from accessing your dashboard, that includes you. Who knew? (Literally everyone but us, apparently.)

Picture us: the feature flag experts locked out of their own feature flag system, SSH-ing into the database server to manually flip a Boolean in production. Peak DevOps energy.

Let's not talk about eating your own dog cat food.

What actually went wrong?

The problem wasn't feature flags. The problem was architecture. We tied operational control to the same access path it was supposed to regulate. In simpler terms: the switch that locked users out also locked out the people who needed to unlock it.

That's not resilience. That's self-inflicted downtime.

The real lesson

Maintenance mode (and any critical kill switch) must follow a few rules:

• Always include admin bypass logic
• Separate operational control from user-facing access
• Provide an out-of-band recovery path
• Test lockout scenarios before enabling them in production

A maintenance flag should never depend on the system it might disable. That's not just a funny story. It's a design principle.

Conclusion

Feature flags are incredibly versatile tools. They can make your life easier, your deployments safer, and your customers happier. But as we've learned the hard way, they're not just convenience switches. But once they control production behavior, they become infrastructure. And infrastructure deserves discipline.

The real power of feature flags isn't just that they let you ship faster, it's that they let you correct course quickly when things don't go as planned.

Used well, they reduce risk. Used carelessly, they create it.

If you're ready to start your own feature flag journey (minus the face-palm moments), ConfigCat offers a forever free plan to help you get started. And don't worry, we've fixed the maintenanceModeEnabled flag since then (Pinky promise!)

You can also follow ConfigCat on X, GitHub, LinkedIn, and Facebook to stay up to date with what we're building next.