Ever wondered if feature flag vendors use their own products?
At Optimizely, we don’t just sell feature flags – we live and breathe them every day.
In fact, we use our Feature Experimentation platform to ship new capabilities to... our Feature Experimentation platform. Yeah, it’s meta. We use feature flags to release feature flags. 🤯
This isn’t a “nice to have.” It’s how we build faster, deploy safer, and innovate at scale.
Before diving into our specific use cases, let’s address why this matters:
The hard truth about feature releases
Most teams are taking unnecessary risks with their feature releases by:
- Pushing directly to production and hoping nothing breaks
- Treating all features with the same deployment process regardless of risk
- Creating bottlenecks where product decisions require engineering deployments
- Building complex branching strategies that delay integration
We know because we’ve been there.
Without feature flags, every release becomes a high-stakes gamble with your UX, engineering time, and revenue on the line.
So, how exactly does Optimizely use our own feature flagging technology?
Here are three real-world examples from our engineering team:
1. Fine-tuning AI features without engineering bottlenecks
Meet Optimizely Agent Platform - your infinite workforce that helps users create better experiments, analyze results, and generate new ideas.
Under the hood, Optimizely Mark is powered by cutting-edge LLM models from our strategic partners like Google and Microsoft. But here’s where it gets interesting.
We use feature flags not just to control whether AI features are ON or OFF, but to fine-tune exactly how they work.
For example, we use feature flags to control:
- Which LLM model powers Optimizely Agent Platform (switching between models as needed)
- How those models are configured (temperature, tokens, parameters)
- What prompt templates we use
- Which user segments get access to which AI capabilities
When instrumenting a feature flag like this, one approach is to hardcode the configuration of the LLM for each variation:
const { createInstance } = require("@optimizely/optimizely-sdk");
import OpenAI from "openai";
const optimizely = createInstance({
sdkKey: "<YOUR_SDK_KEY>",
});
const openAIClient = new OpenAI();
const user = optimizely.createUserContext("user123");
const decision = user.decide("llm_flag");
const variationKey = decision["variationKey"];
if (variationKey === "control") {
// Execute code for control variation
const completion = await openAIClient.chat.completions.create({
model: "gpt-4o",
messages: [
{
role: "user",
content:
"You are a storyteller specializing in whimsical tales. Write a one-sentence bedtime story about a unicorn.", // emphasis on whimsy
},
],
});
} else if (variationKey === "treatment") {
// Execute code for treatment variation
const completion = await openAIClient.chat.completions.create({
model: "gpt-4o-mini",
messages: [
{
role: "user",
content:
"You are a children's author. Write a one-sentence bedtime story about a unicorn.", // emphasis on age-appropriateness
},
],
});
}
The problem? Every change requires developer intervention, creating bottlenecks when you need to move fast.
We do it differently.
Old way? Hardcoded configs = slow iteration.
Our way? Dynamic flag variables = total control, zero deploys.
This approach means our product team can change AI behavior without engineering dependencies. We can test different prompts, switch models, and adjust parameters from our Feature Experimentation dashboard with zero code changes.
const { createInstance } = require("@optimizely/optimizely-sdk");
import OpenAI from "openai";
const optimizely = createInstance({
sdkKey: "<YOUR_SDK_KEY>",
});
const openAIClient = new OpenAI();
const user = optimizely.createUserContext("user123");
const decision = user.decide("llm_flag");
const completion = await openAIClient.chat.completions.create({
model: decision.variables.model, // returned by Optimizely decision
messages: [
{
role: "user",
content: decision.variables.prompt, // returned by Optimizely decision
},
],
});
It led to:
- Dramatically faster time from idea to production for AI features
- More experiments run by product teams with the same engineering resources
- Fewer late-night calls to engineering (bless you, kill switches 💙)
But there’s an even more important benefit: Sleep.
Our engineers no longer get paged at night to fix urgent issues with new AI features, because we can disable problematic ones instantly through our feature flag dashboard.
2. De-risking launches with canary testing
Let’s talk about launch anxiety.
That feeling when you’re about to release a major feature and wait for the support tickets to flood in? That “launch day anxiety?” Yeah, we don’t miss it either.
We use feature flags to run canary tests for gradual, data-informed rollouts that turn risky releases into safe, scalable launches.
When we released our Custom Flags Dashboard, a significant change to core functionality, we didn’t just push it to everyone at once.
Instead, we:
- Released to 5% of customers first (mostly smaller accounts)
- Monitored error rates, performance metrics, and user feedback
- Gradually increased exposure to 20%, then 50%, then 100%
- Provided preemptive notices to customers before they received the change
This approach was both cautious and necessary. Since our platform serves as critical infrastructure for our customers’ feature releases, any disruption could cascade to their users, too.
When we migrated our entire data pipeline to the Google Cloud Platform (GCP), we used feature flags extensively to manage the transition. But canary testing isn’t just for front-end changes. We also used it to roll out infrastructure updates, minimizing risk during deployment gradually.
Using feature flags to control the migration allowed us to:
- Risk mitigation: We could instantly revert if performance degraded
- Business continuity: Our customers depend on continuous data processing
- Validation at scale: We could verify the new systems handled real-world load before full commitment
We completed this massive infrastructure migration with a few customer-reported incidents, despite moving billions of daily events.
The lesson? The bigger the change, the more you need feature flags to de-risk it.
3. Kill switches: Your emergency eject button
Sometimes, stuff breaks (it’s software, we get it).
But there’s a massive difference between “We’re investigating the issue and will deploy a fix soon…” vs. “We turned it off. It’s handled.”
Kill switches are essential because they transform production incidents from all-hands emergencies into controlled, methodical responses.
At Optimizely, every feature has a kill switch - a feature flag that lets us disable it instantly. No code changes. No deploys. No drama.
Our data file build service ensures flag updates reach end-users in mere seconds, rivaling streaming services without the complicated infrastructure.
When we detect issues through our monitoring systems, we can immediately disable the problematic feature, investigate without pressure, and deploy a proper fix during normal working hours. No more late-night emergency deploys.
This capability is particularly critical for our business for several reasons:
- Trust preservation: As a platform that powers our customers’ experiences, minimizing downtime is non-negotiable
- Global impact: With customers across time zones, there’s never a “good time” for an outage
- Complex dependencies: Features often interact in unexpected ways, and quick isolation helps diagnosis
However, flags aren’t a silver bullet...
Feature flags are not a replacement for a solid rollback strategy.
We use our product to release updates to itself (“flags on flags”). In a worst-case scenario where a buggy feature renders the UI inaccessible, we’d be unable to disable the feature remotely.
That’s why our engineering team maintains robust rollback processes alongside feature flags, giving us multiple layers of protection. This layered approach is essential when you’re building critical infrastructure that others depend on.
Feature flags as a product strategy
The use cases above - from AI fine-tuning, canary testing, and kill switches - show that feature flags aren’t just an engineering tool. They’re a product strategy enabler.
By separating deployment from release, we can:
- Move faster: Push code to production continuously without exposing unfinished features
- Experiment more: Test ideas with real users before committing to them
- Reduce risk: Limit exposure and provide instant rollback options
- Empower product teams: Give non-technical stakeholders control over feature rollouts
For our team, feature flags have fundamentally changed how they think about releases. Instead of high-pressure, all-or-nothing launches, we now view releases as a dial that they can turn up gradually while measuring impact.
“Feature flags let us move fast without breaking things. They’re our safety net and our secret weapon.”
— Britt Hall, Sr. Director, Product Management
Where feature flags are heading next
Looking ahead, we see feature flags evolving in several important ways: