Infoveave Engineering Team···8 min read

Feature Flags — The Deployment Superpower You Are Probably Not Using

What you will learn: What feature flags are, the four types, how to target them to specific users and regions, how to keep them clean, and when to build vs buy.

The Friday Problem

Every developer knows this feeling. It is 5 PM on a Friday. Your code is reviewed, merged, and the pipeline is green. But nobody deploys on Friday — because if something breaks, you are fixing it at 2 AM.
Feature flags are the engineering answer to this fear.
The core idea: deploy your code to production, but control who sees it. The code is live. The feature stays invisible until you decide to turn it on — for whoever you choose.
csharp
public IActionResult GetDashboard()
{
    if (_flags.IsEnabled("new_dashboard", userId))
        return View("NewDashboard");

    return View("OldDashboard");
}

The Four Types of Feature Flags

Not all flags are the same. Mixing them up is how teams end up with a mess.
TypeWhat It DoesLifetime
Release FlagHides an incomplete feature while you build it. Delete once fully live.Days to weeks
Experiment FlagA/B testing. Route 50% to old, 50% to new. Measure. Winner survives.Duration of experiment
Ops FlagKill switch. Turn off a heavy feature instantly if it hurts your DB. No deployment needed.Permanent, rarely toggled
Permission FlagFree users see basic export. Pro users see advanced export. Cleaner than hardcoded role checks.Permanent

How Targeting Works — The Context Object

Every flag evaluation takes a context object — a bundle of information about the current user that the flag engine uses to make its decision.
csharp
var context = new EvaluationContext
{
    UserId  = "user_9821",
    Plan    = "enterprise",
    Region  = "South India",
    City    = "Bengaluru",
    Country = "IN",
    Company = "Infoveave",
    Role    = "admin",
    Custom  = new Dictionary<string, string>
    {
        { "accountAge", "18months" }
    }
};

bool showFeature = _flags.IsEnabled("new_report_builder", context);
You pass this context on every flag call. The engine compares it against your targeting rules and returns true or false.

Targeting Rules — Who Sees What and Why

Incoming RequestFlag enabledglobally?NoOFFYesMatches targetingrules?NoOFFYesIn percentagebucket?NoOFFYesON ✓userIdplanregion

By User ID

Good for internal testing — turn it on for your own account first.
userId IS IN ["user_001", "user_002"]

By Region or City

Test a new checkout flow in Karnataka before rolling out across India.
region IS IN ["Karnataka", "Maharashtra"]

By Customer Plan

Advanced export should only be visible to Pro and Enterprise customers.
plan IS IN ["pro", "enterprise"]

By Company

In B2B products, enable for one client before everyone else sees it.
company IS IN ["Infoveave", "TataConsultancy"]

Combining Rules

Rules can use AND / OR logic for surgical precision.
plan IS "enterprise"
  AND region IS "South India"
  AND role IS "admin"
→ Only enterprise admins from South India see this feature

Percentage Rollouts — Gradual Exposure

When you do not want to target specific attributes but want to slowly open the feature, use a percentage rollout with consistent hashing:
csharp
public bool IsInRollout(string userId, string flagKey, int percentage)
{
    string input = $"{userId}:{flagKey}";
    using var md5 = MD5.Create();
    byte[] hash  = md5.ComputeHash(Encoding.UTF8.GetBytes(input));
    int bucket   = Math.Abs(BitConverter.ToInt32(hash, 0)) % 100;
    return bucket < percentage;
}
Same userId + flagKey always produces the same hash — so the same user never randomly flips between old and new experiences across sessions.
A realistic rollout ladder:
PhaseRuleWho Sees It
Week 1userId IN [your team]Just your dev and QA team
Week 2company IS "BetaClient"One trusted client
Week 3plan IS "enterprise" AND region IS "South India"Enterprise users, South India only
Week 4plan IS "enterprise" + 50% rolloutHalf of all enterprise users
Week 5plan IS "enterprise"All enterprise users
Week 6100% rolloutEveryone — then delete the flag

Dual Evaluation — Frontend and Backend

Never check flags only in React. A user can inspect your JS bundle and enable hidden features. Always evaluate on both layers.
csharp
// .NET — evaluate on the server, send decisions to frontend
var features = new {
    newReportBuilder = _flags.IsEnabled("new_report_builder", userId),
    advancedExport   = _flags.IsEnabled("advanced_export", userId)
};
tsx
// React — consume via context hook
const ReportPage = () => {
    const hasNewBuilder = useFeature("newReportBuilder");
    return hasNewBuilder ? <NewReportBuilder /> : <OldReportBuilder />;
};
csharp
// API — gate the endpoint too, not just the UI
[HttpPost("report/advanced")]
public IActionResult GenerateAdvancedReport()
{
    if (!_flags.IsEnabled("advanced_export", GetUserId()))
        return Forbid();
}
A hidden UI button is a UX decision. A hidden API endpoint that still responds is a security hole.

Flag Ownership and Expiry — The Rule Nobody Follows

In August 2012, Knight Capital deployed new software to eight of nine servers. The ninth had a stale, forgotten feature flag that activated a broken trading algorithm. It ran for 45 minutes. They lost $440 million — roughly ₹3,700 crore. The company was sold within days. (SEC Administrative Proceeding, 2013)
The flag was not the bug. The forgotten flag was the bug.
Every flag you create must have three things:
  • An owner — who is responsible for cleaning it up
  • A creation date — when was it added
  • An expiry date — after which it must be reviewed or deleted
Use a naming convention like ff_2025_q2_new_report_builder. In 18 months, this tells you exactly when it was created and what it controls. A name like newReportBuilder tells you nothing.

Performance Considerations

1. Caching Flag Evaluations

If you evaluate the same flag multiple times in a single request, you get unnecessary repeated computation or network calls:
csharp
// Avoid — called twice
_flags.IsEnabled("new_dashboard", userId);
_flags.IsEnabled("new_dashboard", userId);
Cache the result per request instead:
csharp
var featureCache = new Dictionary<string, bool>();

bool IsEnabledCached(string key, string userId)
{
    if (!featureCache.ContainsKey(key))
        featureCache[key] = _flags.IsEnabled(key, userId);

    return featureCache[key];
}

2. Batching Evaluations

Instead of calling the flag service once per flag:
csharp
// Avoid — three round trips
var a = _flags.IsEnabled("A", userId);
var b = _flags.IsEnabled("B", userId);
var c = _flags.IsEnabled("C", userId);
Fetch all flags in one call:
csharp
// Prefer — one round trip
var features = _flags.GetAll(userId);
features["A"];
features["B"];
features["C"];
Batching reduces network calls, improves response time, and keeps the flag service from becoming a bottleneck under load.

Build vs Buy

OptionBest ForCost
Roll your ownRelease and permission flags only. Small teams.Free — dev time
UnleashOpen source, self-hosted. Solid .NET SDK.Free (self-hosted)
PostHogFlags + A/B testing + session recordings.Generous free tier
LaunchDarklyIndustry gold standard. Full targeting, audit logs.Paid
If you only need release and permission flags — roll your own or use Unleash. If you need A/B experiments with metric tracking — use a managed service.

The Key Takeaway

A feature flag is not just an on/off switch. It is a targeting engine that asks one question at runtime:
"Given everything I know about this user — their plan, region, role, company — should they see this feature right now?"
Start with userId for internal testing. Add plan for plan-based access. Add region for geographic rollouts. Combine them for precision. Set expiry dates so you are not the next Knight Capital story.
Deploy continuously. Release deliberately. Clean up always.

How We Use This at Infoveave

Infoveave is a multi-tenant platform where different customers are on different subscription tiers. Feature flags are how we control which platform capabilities are visible per plan — a customer on the standard tier should not see the Fovea AI query builder if they haven't licensed it, and that gate needs to exist at both the UI and the API layer. We also use release flags when shipping major new features — the code ships dark, we enable it for internal users first, validate it on real data, then roll it out by plan tier. The Knight Capital story in this article is one we reference in internal engineering reviews. Stale flags with no owner are a category of technical debt we actively track and retire on a schedule.

About the Authors

This article was written by the Infoveave Engineering Team — building Unified Data Platform, agentic BI, and enterprise analytics infrastructure. Infoveave (by Noesys Software) helps organisations unify data, automate business processes, and act faster with AI-powered insights.

Ready to see Infoveave in action?

Book a Demo
ISO 27001ISO 27017ISO 27701GDPRHIPAACCPAAICPACSR LogoCapterra Reviews — Infoveave

© 2026 Noesys Software Pvt Ltd

Infoveave® is a product of Noesys

All Rights Reserved