DEV Community: AvlCodeMonkey Industries

Build vs Buy: You Don't Need Another Side Project

AvlCodeMonkey — Wed, 02 Sep 2026 16:32:47 +0000

When you first need feature flags in a .NET application, the answer is wonderfully boring. Install Microsoft.FeatureManagement, put some flags in appsettings.json, and you're off to the races. Microsoft handles the feature evaluation plumbing, filters, targeting, and ASP.NET Core integration. And honestly?

That works great.

For a small application with a handful of flags, you probably don't need anything more. Then things grow. Suddenly your appSettings.json has become a feature management database with worse UX.

When Configuration Becomes a Product

The problem isn't evaluating a flag. That's easy. The problem is everything around it. What if a product manager wants to enable a feature without asking a developer? What if you want to change a flag without rebuilding and redeploying the application? What if you have multiple environments and enough flags that nobody remembers which configuration file is currently lying to them?

At that point, you're not really managing configuration anymore. You're building a feature flag platform. And that's where the build-vs-buy question gets interesting.

But AI Makes Building It Easy... Right?

Well, yes. AI has made generating code dramatically cheaper. You can ask an AI to build:

A feature flag API
An admin UI
A database schema
An SDK
Authentication
Deployment scripts

...before your coffee gets cold. Congratulations. You have something that works. You have not eliminated:

Maintenance and security updates
Hosting and infrastructure costs
Backups
Monitoring
Documentation
Support and on-call
Future-you wondering why past-you volunteered for this

AI reduces the cost of writing software. It doesn't necessarily reduce the cost of owning software. That's an important distinction.

Build vs Buy Isn't About Code

The real question isn't:

"Can I build this?"

Of course you can. The question is:

"Do I want to keep building and maintaining this?"

That's a very different question. If you're building a SaaS product, your engineering time is probably better spent on the things that give your product a competitive advantage. Not on building an admin interface for toggling booleans. Not on figuring out how to back up your feature flag database. Not on discovering that your homemade flag service has been down for three hours because nobody configured monitoring. And definitely not on becoming the proud maintainer of Yet Another Internal Platform™.

So... Build or Buy?

There isn't a universal answer. For a simple application with three flags?

Build it.

Seriously. Microsoft already provides the feature management library. Put the flags in configuration and move on with your life. For a growing application where non-technical people need to safely manage features without touching JSON files or deployment pipelines?

That's where a focused third-party solution starts looking pretty attractive. You get a proper management interface while your developers stay focused on building the actual product. That's the trade-off.

Build your product. Buy the plumbing.

If you're looking for a simple way to manage .NET feature flags without turning feature management into another project, check out FeatureFlags.app. Your developers will thank you. Probably.

Microsoft Feature Management Quirks (and How to Survive Them)

AvlCodeMonkey — Fri, 21 Aug 2026 16:33:44 +0000

Microsoft.FeatureManagement is solid, widely used, and much better than building your own feature flag framework in a caffeine panic. But it has quirks. None are fatal. Most are avoidable if you know where the sharp edges are.

Your Flag Names Are Strings Forever

Feature names are strings. That means typos compile perfectly and fail at runtime in the most boring way possible. You configure:

{
  "FeatureManagement": {
    "NewDashboard": true
  }
}

Then check:

await _featureManager.IsEnabledAsync("NewDashbaord");

Spot the typo? The compiler doesn't. Your shiny new UI never appears, and you spend an afternoon questioning your life choices.

The Fix

Centralize your flag names.

public static class FeatureFlags
{
    public const string NewDashboard = "NewDashboard";
    public const string ExperimentalSearch = "ExperimentalSearch";
}

Then use them everywhere:

await _featureManager.IsEnabledAsync(FeatureFlags.NewDashboard);

Or build a strongly typed wrapper if your application has enough flags to justify it. The important part is simple:

Stop scattering magic strings throughout your controllers, services, tag helpers, and filters.

Your typo budget is already being spent elsewhere.

Configuration Shape Is Less Forgiving Than It Looks

The library expects a specific configuration layout under FeatureManagement. If you typo the section name, misconfigure EnabledFor, or get creative with the JSON structure, your flags may not behave as expected. Then it looks like the framework is "ignoring" your configuration. It isn't. Your JSON is probably wrong.

The Fix

Keep one canonical configuration example in your repository. Test it. Validate important configuration through integration tests. And avoid turning appsettings.json into an experimental art project. A known-good example is much easier to maintain than debugging configuration structure at 4pm on a Friday.

Filter Behavior Depends on Context Quality

Percentage rollouts sound straightforward. Enable a feature for 20% of users. Easy. Except PercentageFilter evaluates randomly, so the same user can potentially get different results across requests. That's fine for coarse rollouts. It's less fine when you expect a user to consistently see the same version of a feature.

The Fix

If you need stable per-user behavior, use ConsistentPercentageFilter.

In ASP.NET Core scenarios, it can use the current principal identity as a stable user key and assign that user to a deterministic bucket. The catch? Your context still matters. If the user identity is missing or changes between requests, the results can still look random. So before blaming the feature flag library, make sure you're actually giving it a consistent identity.

Garbage context in. Confusing rollout behavior out.

`IsEnabledAsync` Everywhere Means You Can Re-Evaluate a Lot

Feature flag checks are asynchronous. They're also extremely easy to sprinkle throughout your application:

if (await _featureManager.IsEnabledAsync(FeatureFlags.NewDashboard))
{
    // Do something
}

Then somewhere deeper in the same request:

if (await _featureManager.IsEnabledAsync(FeatureFlags.NewDashboard))
{
    // Do something else
}

And again. And again. Before long, you're evaluating the same flag multiple times in one request path.

The Fix

When appropriate, evaluate the flag once and pass the result through the relevant operation.

var isNewDashboardEnabled =
    await _featureManager.IsEnabledAsync(FeatureFlags.NewDashboard);

// Use isNewDashboardEnabled throughout this operation

This gives you clearer behavior and fewer opportunities for surprising changes between evaluations.

`IFeatureManager` vs. `IFeatureManagerSnapshot`

You can inject either IFeatureManager or IFeatureManagerSnapshot. And the choice matters. For request-heavy applications, snapshot semantics are often what you actually want. IFeatureManagerSnapshot provides consistency for the lifetime of a request or scope, so repeated checks can use the same evaluated state. That's useful when you don't want feature behavior changing halfway through an operation.

The Fix

Prefer IFeatureManagerSnapshot when consistent per-request behavior matters. Be intentional when using the non-snapshot manager. The important question isn't:

"Which interface compiles?"

They both do.

The question is:

"Could evaluating this flag differently during the same operation cause problems?"

If the answer is yes, snapshot semantics are probably worth considering.

None of This Is a Dealbreaker

Microsoft's feature management library is still a great default choice for .NET applications. Most of the pain comes from:

Naming drift
Configuration mistakes
Context assumptions
Repeated evaluations
Not thinking about evaluation consistency

The framework is fine. Your future self just wants fewer typo-driven incidents. Add some guardrails, centralize your flag names, test your configuration, and understand how your filters and evaluation scope behave. Then you get the benefits of feature flags without quite as many mystery bugs.

And if you're tired of managing flags through configuration files, FeatureFlags.app gives you a central place to manage them without turning every flag change into an adventure.

Know the quirks. Add the guardrails. Ship anyway.

Cleaning Up Feature Flags: The Art of Not Leaving a Mess

AvlCodeMonkey — Thu, 20 Aug 2026 18:39:52 +0000

You said you'd remove that flag after launch. You lied. It's been six months and the flag is still in appsettings.json, the if statement is still in your controller, and nobody remembers which state is "on." This is how codebases turn into haunted houses.

Why Cleanup Matters

Dead feature flags are technical debt with teeth. They add branches to your code that nobody tests. They confuse new developers who don't know the history. They inflate configuration files and make deployments harder to reason about. And they compound.

Every flag you don't clean up makes the next cleanup harder because the cognitive load of understanding the system keeps increasing. The cost of removing a flag is lowest immediately after the feature ships, while everyone still remembers what the thing does. Six months later? Good luck.

Track Every Flag

You can't clean up what you can't find. Maintain a registry of every active feature flag with:

Name
Purpose
Owner
Date created
Expected removal date

This can be a spreadsheet, an issue tracker, internal documentation, or a dedicated feature flag management system. The format doesn't matter nearly as much as the habit. When you add a flag, add it to the registry. When you remove a flag, remove it from the registry. If your registry contains flags with no owner or no removal date, congratulations: you've found your next cleanup project.

Set Expiry Dates

Every flag should have a planned removal date when it's created. For example:

Release toggles: Remove shortly after the feature ships. Two weeks is a reasonable default.
Experiment toggles: Remove when the experiment concludes.
Ops toggles: May be permanent by design.
Permission toggles: May also be permanent, but document that explicitly.

If a flag has been alive longer than its planned expiry and nobody deliberately extended it, it's already a zombie. Treat it accordingly.

Make Cleanup Part of the Process

Flag cleanup doesn't happen unless someone owns it. Add a cleanup step to your feature completion checklist. Better yet, create the cleanup ticket when you create the feature ticket. The feature isn't done when it's released. It's done when the flag is gone.

Some teams set automated alerts when flags exceed their planned lifetime. Others track flag counts on engineering dashboards. The specific mechanism doesn't matter much. Having a mechanism does.

How to Actually Remove a Flag

Removing a flag isn't just deleting an if statement. Here's the full checklist:

Determine which state the flag should permanently be in. Usually enabled if the feature shipped successfully.
Remove the flag check and keep the code from the permanent path.
Delete the disabled code path completely. Don't comment it out.
Remove the flag definition from configuration and your flag management system.
Update or remove tests that specifically covered the disabled state.
Delete the flag from your registry.
Deploy and verify.

Step 3 is where people get lazy. Commented-out code isn't deleted code. It's just code waiting to confuse someone six months from now. Delete it.

The Goal

A well-maintained codebase has only the feature flags it actually needs. Each flag should be:

Documented
Owned
Understandable
Actively used
Scheduled for removal

Clean up isn't a one-time event. It's an ongoing engineering practice. Feature flags should make your system easier to operate, not turn it into an archaeological dig.

If you want to make it easy to clean up your feature flags without editing configuration files in production, check out FeatureFlags.app.

The only good zombie flag is a deleted one.

Feature Flags and Testing: Because QA Deserves Surprises Too

AvlCodeMonkey — Wed, 19 Aug 2026 17:59:43 +0000

Feature flags solve a lot of deployment problems. They also create a whole new set of testing problems. Every flag introduces a branch in your code. Every branch needs to be tested. The math gets uncomfortable fast.

The State Explosion Problem

One feature flag means two states: On. Off.

Two flags means four states. Ten flags means 1,024 possible combinations.

You are not going to test all of them. Nobody is. But some of those combinations will behave unexpectedly, and your users will find them at the worst possible time. The practical approach is to identify which flag combinations actually matter for your application and test those specifically.

Flags that affect the same feature or code path are more likely to interact badly. Flags for completely independent features probably don't need to be tested together.

Test Every State of Every Flag

At a minimum, every flag should be tested in both its enabled and disabled states. This sounds obvious. It's also incredibly easy to forget. When adding a flag, developers tend to test the shiny new code path and forget to verify that the old path still works. Don't. Write explicit tests for both states:

[Fact]
public async Task Index_ReturnsNewDashboard_WhenFlagEnabled()
{
    // Arrange
    _featureManager
        .Setup(fm => fm.IsEnabledAsync("NewDashboard"))
        .ReturnsAsync(true);

    // Act
    var result = await _controller.Index();

    // Assert
    var viewResult = Assert.IsType<ViewResult>(result);
    Assert.Equal("NewDashboard", viewResult.ViewName);
}

[Fact]
public async Task Index_ReturnsOldDashboard_WhenFlagDisabled()
{
    // Arrange
    _featureManager
        .Setup(fm => fm.IsEnabledAsync("NewDashboard"))
        .ReturnsAsync(false);

    // Act
    var result = await _controller.Index();

    // Assert
    var viewResult = Assert.IsType<ViewResult>(result);
    Assert.Equal("OldDashboard", viewResult.ViewName);
}

Both tests matter. Don't skip the disabled case.

That's usually the code path everyone assumes will keep working forever.

Test the Flag Infrastructure

Here's another fun question: What happens when your flag service is unavailable?

Nobody's perfect. Your application should have a defined behavior when the flag infrastructure goes down. A safe default is usually to treat the flag as disabled. And yes, that behavior should be tested. "Works on my machine when the flag server is up" is not a test strategy.

Write tests that simulate a flag service outage and verify that your application degrades gracefully. Users shouldn't see an error because a configuration service had a brief hiccup. The important part is that you know what happens and you've tested it.

Automate Everything

Manual testing of feature flag states doesn't scale. Have ten active flags? Asking QA to manually verify both states of every flag before every release is a fantastic way to produce burnout, missed coverage, and possibly a strongly worded email.

Automate it. Your CI pipeline should run your flag-state tests automatically. Use mocks or test configuration to control flag values in your test suite.

Don't make your CI pipeline depend on a live flag server.

Your tests should be deterministic. Your production infrastructure can provide enough chaos on its own.

Document Expected Behavior

For every flag, document what the application should do when the flag is:

Enabled
Disabled

That documentation becomes the specification your tests enforce. Without documentation, "works on my machine" becomes the de facto specification. With documentation, everyone has a shared understanding of what correct behavior actually means. That makes it easier to:

Write tests
Review code
Diagnose bugs
Understand old flags
Remove flags safely

It also makes explaining expected behavior to the person filing the bug report considerably easier.

The Point

Feature flags give you control. Testing makes sure that control doesn't turn into chaos. For every flag:

Test the enabled state.
Test the disabled state.
Test important flag combinations.
Test what happens when the flag infrastructure fails.
Automate the tests in CI.
Document the expected behavior.

And when the feature is fully released?

Delete the flag.

Fewer flags mean fewer states, fewer tests, and fewer opportunities for your codebase to develop a personality disorder.

If you need a simple way to manage your feature flags without building your own flag infrastructure, check out FeatureFlags.app.

Test everything. Automate all of it. Document what you expect. Try not to cry.

Implementing Feature Management in .NET: The Lazy Way

AvlCodeMonkey — Tue, 18 Aug 2026 18:57:53 +0000

Microsoft did the hard work so you don't have to.

The Microsoft.FeatureManagement library integrates directly with .NET's configuration and dependency injection systems, which means you can get feature flags working with minimal code and a solid foundation. For the full documentation, check out the Microsoft Feature Management documentation.

Let's get this thing running.

Installation

Add the NuGet package to your project:

dotnet add package Microsoft.FeatureManagement.AspNetCore

That's it for dependencies. No magic rituals required.

Configuration

builder.Services.AddFeatureManagement();

By default, feature flags are read from the FeatureManagement section of your appsettings.json:

{
  "FeatureManagement": {
    "NewDashboard": true,
    "ExperimentalSearch": false
  }
}

Flag names are strings. Values are booleans. Simple.

Checking a Flag in Code

Inject IFeatureManager wherever you need to check a flag:

public class DashboardController : Controller
{
    private readonly IFeatureManager _featureManager;

    public DashboardController(IFeatureManager featureManager)
    {
        _featureManager = featureManager;
    }

    public async Task<IActionResult> Index()
    {
        if (await _featureManager.IsEnabledAsync("NewDashboard"))
        {
            return View("NewDashboard");
        }

        return View("OldDashboard");
    }
}

That's the whole pattern. Inject. Check. Branch. Repeat.

Using Feature Filters

Boolean flags are useful, but sometimes you need something a little more sophisticated. The library supports feature filters for things like:

Percentage rollouts
Time windows
User targeting

For example, you can enable a feature for a percentage of requests:

{
  "FeatureManagement": {
    "BetaFeature": {
      "EnabledFor": [
        {
          "Name": "Percentage",
          "Parameters": {
            "Value": 20
          }
        }
      ]
    }
  }
}

This enables BetaFeature for 20% of requests. The library handles the sampling. You handle the business logic. Everybody wins.

Razor Tag Helpers

Building a Razor-based UI? The library includes a tag helper for conditionally rendering markup:

<feature name="NewDashboard">
    <div class="new-dashboard">...</div>
</feature>

Clean, readable, and no C# in your markup. Some people consider this progress.

The Lazy Way Is Often the Right Way

Rolling your own feature flag system is a rite of passage. It's also probably not a good use of your time. Microsoft's library already handles the plumbing:

Configuration
Dependency injection
Feature filters
Percentage rollouts
Razor tag helpers

So you can focus on the actual feature instead of spending three days building a flag system that was supposed to take an afternoon.

But there's one problem with the appsettings.json approach:

Someone still has to edit the config file when you want to flip a flag.

And if that means changing configuration, committing it, deploying it, and waiting for the pipeline just to turn off a broken feature...

You've basically recreated the problem feature flags were supposed to solve.

A dedicated feature flag management UI lets you change flags without touching your configuration files or redeploying your application.

That's where FeatureFlags.app comes in.

Why reinvent the wheel when someone already built the wheel factory?

Be lazy. Ship more.

Feature Flags and Continuous Delivery: Ship It Like You Mean It

AvlCodeMonkey — Mon, 17 Aug 2026 19:56:08 +0000

Continuous delivery means shipping code to production frequently — ideally on every merge to main. Feature flags are what make that possible without turning every deployment into a high-stakes gamble.

The Core Problem: Deployment vs. Release

There's an important distinction that many teams blur:

Deploying code and releasing features are not the same thing.

Deployment means putting code on a server. Release means making a feature visible to users. In a traditional workflow, these happen together. You deploy, and the feature immediately goes live. With feature flags, you can separate them. That's the foundation of continuous delivery:

Deploy constantly. Release deliberately.

The feature flag controls when code goes from deployed to released. As Scott Hanselman puts it, feature flags let you separate deployment from release, giving you the power to experiment and react quickly. That's a pretty useful superpower.

Test in Production (Carefully)

Staging environments are valuable. They're also never quite the same as production. Real traffic patterns. Real data volumes. Real third-party integrations. Staging approximates these things, but it doesn't perfectly replicate them.

Feature flags let you test in production in a controlled way. Enable a new feature for internal users only. Or expose it to a small percentage of real traffic. Then watch what happens.

This isn't the same as shipping broken code to everyone and hoping for the best. It's a deliberate strategy for gathering production signal before committing to a full rollout. Your users become your test environment. Just... carefully.

Instant Rollback Without a Redeployment

Traditional rollbacks require reverting a deployment. That takes time, especially when your deployment pipeline has multiple steps, approvals, and enough YAML to qualify as a cry for help.

With feature flags, rollback is just flipping a switch. If a newly released feature starts causing problems, disable it in seconds. The bad code is still in production, but it's no longer running. You've bought yourself time to investigate and fix the problem without immediately rolling back the entire deployment. Your weekend is now slightly safer.

Trunk-Based Development

Feature flags also make trunk-based development practical. Instead of maintaining long-lived feature branches, developers commit to the main branch frequently — often daily. But what happens when a feature isn't finished?

Hide it behind a flag.

The incomplete code can be merged and deployed without exposing it to users. This means developers can integrate early and often instead of maintaining massive branches that eventually collide in a spectacular merge-conflict apocalypse.

Trunk-based development can:

Reduce merge conflicts
Improve integration quality
Encourage smaller, more frequent deployments
Simplify the delivery pipeline

Feature flags are the mechanism that makes unfinished work safe to deploy.

What This Looks Like in Practice

With feature flags and continuous delivery working together, your workflow might look something like this:

Set up a flag management server so you're not editing appsettings.json in production like an animal.
Write the code. Wrap it in a flag. Merge to main.
Deploy to production with the flag off.
Enable the flag for internal users. Watch your metrics.
Gradually roll it out to a wider audience.
Fully release the feature.
Remove the flag.

Each step is reversible. Each step gives you more confidence. And if something goes wrong at any point, flip the flag and investigate. No emergency redeployment required.

The Point

Feature flags aren't just about turning features on and off. They're a key part of separating deployment from release. That separation gives your team the freedom to:

Deploy frequently
Test changes with real production traffic
Roll out features gradually
Disable broken functionality instantly
Keep incomplete work off long-lived branches
Practice continuous delivery without treating every deployment like a tripwire

The goal isn't to eliminate risk. It's to make the risk manageable.

If you want to manage your feature flags without editing configuration files in production, check out FeatureFlags.app.

Ship constantly. Release deliberately. Sleep soundly.

Feature Flag Pitfalls: How to Turn Your Codebase Into a Haunted House

AvlCodeMonkey — Mon, 17 Aug 2026 19:51:51 +0000

Feature flags are easy to add and hard to remove. That asymmetry is where the trouble starts.

Used properly, feature flags give you safer deployments, gradual rollouts, and emergency kill switches. Used poorly, they turn your codebase into a haunted house full of dead branches nobody dares to touch.

Here are some of the most common ways feature flags go wrong.

Zombie Flags

A zombie flag is a flag that should have been deleted months ago but wasn't.

The feature shipped. The experiment ended. Everyone moved on. But the flag?

Still there.

Nobody remembers what it does, why it exists, or whether removing it will summon Cthulhu.

Zombie flags accumulate over time. Eventually your codebase is full of if statements that will never execute, conditions that are always true, and dead code paths nobody has tested in years.

It's technical debt with extra steps.

The fix

Treat flag cleanup as part of the feature work. When you create a flag, decide when it should go away. Put the removal task in the ticket. Assign an owner. Set a reminder. Do whatever it takes.

Don't let flags outlive their purpose.

Flag Explosion

One flag? Fine.

Ten flags? Manageable.

Fifty flags?

Better start looking for that spreadsheet.

A hundred flags?

Congratulations. You have more feature flags than features.

Flag explosion happens when teams add flags without a policy for removing them. Every new feature gets a flag "just in case," and somehow "just in case" becomes "forever."

Now every deployment requires checking a giant configuration table before you can figure out what users are actually going to see.

The fix

Keep track of:

What each flag does
Who owns it
Why it exists
When it should be removed

If a flag has no owner and no expiration plan, it's already a zombie waiting to happen.

Or, instead of maintaining yet another spreadsheet that everyone forgets exists, use a feature flag management tool that tracks this stuff for you.

Because the spreadsheet you create at 2pm is definitely going to be updated when you're shipping at midnight.

Right?

Testing Complexity

Here's where feature flags get mathematically unpleasant.

Every binary feature flag can double the number of possible states your application can be in.

Two flags?

4 combinations.

Ten flags?

1,024 combinations.

Twenty flags?

1,048,576 combinations.

You probably don't have time to test all of those.

Neither does your QA team.

In practice, not every combination matters. But eventually you'll hit one that does, and you'll probably discover it when a user finds the exact combination you didn't test.

The fix

Minimize the number of active flags.

Retire old flags aggressively.

Don't let temporary rollout flags become permanent application architecture.

The longer a flag sticks around, the more combinations you have to reason about.

Missing Documentation

"What does EnableSuperMode do?"

"No idea. Don't touch it."

This conversation happens at every company that uses feature flags without documenting them. The original developer left. The ticket was closed. The Slack thread disappeared into the void. And now everyone is terrified to remove the flag because nobody knows what happens when you flip it.

Every flag should have:

A name that explains what it does
A description of why it exists
An owner
A plan for when it should be removed

If you can't explain a flag in one sentence, it's probably not ready to ship.

The Bottom Line

Feature flags are powerful. But power comes with responsibility, blah blah blah. The important part is:

Add them intentionally.

Document them thoroughly.

Remove them ruthlessly.

Feature flags should make your codebase easier to operate, not turn it into an archaeological dig.

If you're managing more than a handful of flags, a dedicated flag management tool can help you keep track of what's active, who owns it, and what needs to be cleaned up.

Try FeatureFlags.app and stop letting your feature flags become zombies.

The only good zombie flag is a deleted one.

Feature Flags in the Real World: Use Cases That Won't Get You Fired

AvlCodeMonkey — Mon, 17 Aug 2026 19:48:33 +0000

Why do teams use feature flags?

Because "move fast and break things" is only fun until you break prod.

Feature flags let you move fast and break things slightly less dramatically.

Here’s how real engineering teams actually use them.

Canary Releases

A canary release means you roll out a change to a small percentage of users first—say, 1%—before exposing it to everyone.

If the 1% starts screaming, you flip the flag off and investigate.

If they don't notice anything wrong, you gradually increase the rollout.

The name comes from the old mining practice of bringing a canary into a coal mine to detect toxic gases.

Your early users are the canary.

Hopefully, nothing explodes.

This pattern is especially valuable for high-traffic systems where even a small bug can affect thousands of users. Rolling out slowly gives you real production signal without betting the whole user base on it.

A/B Testing

A/B testing with feature flags means showing two different versions of a feature to different groups of users and measuring which performs better.

Want to know if the green button converts better than the blue one?

Wrap it in a flag, split your traffic, and let the data decide.

The flag controls group assignment. Your analytics platform measures the outcome.

When the experiment concludes, you ship the winner and delete the flag.

Simple in theory.

Slightly painful in practice when the experiment runs for six months and everyone forgets what you were testing.

Kill Switches

Sometimes things go wrong in production.

A third-party API starts returning garbage. A database query locks everything up. A new feature is causing unexplained memory leaks.

You need to turn it off immediately, without rolling back a deployment or waking up the release manager.

That's where kill switches come in.

Kill switches are ops-style feature flags that exist specifically for these moments. They're always off by default and flipped on only in emergencies.

With a kill switch in place, the on-call engineer can disable a problematic feature in seconds rather than scrambling through a deployment pipeline at 2am.

Your future, sleep-deprived self will thank you.

Beta Testing and Early Access

Feature flags let you give specific users early access to new functionality before it's fully released.

Power users. Internal testers. Customers in your beta program.

Basically, anyone you trust to find bugs before the general public does.

This lets you collect real feedback on a real feature without committing to a full release.

If the feedback is bad, disable it for the beta group and go back to the drawing board.

If the feedback is good, roll it out to everyone.

The flag controls access. Your users do the testing.

Managing which users are in the beta group is a lot easier from a web UI than from a config file.

A dedicated flag management tool can handle this without making you write custom targeting logic for every new beta cohort.

Dark Launches

A dark launch means you run new code in production but don't show its output to users.

You're testing performance and correctness under real load without making any user-visible change.

The flag enables the code path. The results go to a log or metrics system instead of the UI.

Dark launches are particularly useful for risky backend changes:

New database queries
Algorithm replacements
Infrastructure migrations
Performance-sensitive changes

You get production-scale validation before committing to the new implementation.

That's a much nicer way to discover that your clever new database query takes 45 seconds than discovering it after you've deployed it to 100% of your users.

The Point

Feature flags aren't just a fancy on/off switch.

They're a way to separate deployment from release and give your team more control over what happens after code reaches production.

Use them for:

Canary releases
A/B testing
Kill switches
Beta and early access
Dark launches
Safer production rollouts

Use feature flags.

Break things more safely.

Look like a genius when nothing goes wrong.

And if you want a simple way to manage your flags without building your own admin UI, check out FeatureFlags.app.

Ship it.

Unlocking the Power of Feature Flags

AvlCodeMonkey — Mon, 17 Aug 2026 19:41:17 +0000

So, you shipped a new feature.

Congrats! 🎉

Now the app's acting weird.

Do you nuke the whole release?

Nah. Enter feature flags.

What Are Feature Flags?

Feature flags (aka feature toggles, aka "please don't break prod") let you flip features on or off without redeploying.

It's like hiding switches all over your codebase, so you can turn stuff on for your favorite users—or just yourself, let's be honest—and turn it off when things inevitably go sideways.

Martin Fowler calls feature flags:

"a powerful technique, allowing teams to modify system behavior without changing code."

Translation: you can break things more safely.

Why Use Feature Flags?

Let's say you want to test a new feature, but only on Dave's machine because he's the only one who reads the docs.

Or maybe you want to roll out a change slowly, just in case it's cursed.

Feature flags let you:

Deploy Safely — Ship code to production while keeping the scary stuff hidden.
A/B Test — Show different features to different users and pretend you're doing science.
Instant Rollback — Flip a switch and pretend nothing ever happened.
Continuous Delivery — Ship all the time and break things less. In theory.

As Scott Hanselman puts it, feature flags let you separate deployment from release, giving you the power to experiment and react quickly.

That's a pretty useful superpower.

How Do Feature Flags Work?

It's just a boolean, folks.

On or off.

Store the flag in your code, a database, or some SaaS. Your application checks the flag before running the relevant code.

You can make it as complicated as you want—user-specific, time-based, or tied to the phase of the moon.

Here's a basic example in C#:

public async Task<IActionResult> Index()
{
    if (await _featureManager.IsEnabledAsync("NewDashboard"))
    {
        return View("NewDashboard");
    }

    return View("OldDashboard");
}

Simple enough.

But if editing appsettings.json every time you want to flip a flag sounds like a bad time, you're not wrong.

A central flag management server with a proper web UI is the better move:

No config file edits
No redeployments
No waiting for CI/CD
Just a switch you can flip from a browser

If you're impatient, FeatureFlags.app is free to try.

The Code Monkey's Caution

With great power comes great spaghetti.

Too many flags and your codebase becomes a haunted house.

Label your flags. Document them. Delete them when you're done.

You won't.

But you should.

Conclusion

Feature flags help you:

Ship safely
Experiment with new functionality
Roll out changes gradually
Turn off broken features without a redeploy
Separate deployment from release

Use them wisely, and maybe you'll survive your next production release.

And if you want a simple way to manage your flags without wrestling with config files, give FeatureFlags.app a try.

Case closed. For now. Go get coffee.

Fear Is the Mind-Killer. Dependencies Are the Build-Killer

AvlCodeMonkey — Tue, 11 Aug 2026 16:02:38 +0000

Remember when adding a package was just:

npm install some-random-thing

What could possibly go wrong? Well... Shai-Hulud happened. The recent Shai-Hulud supply-chain attacks are a particularly nasty reminder that every dependency is an invitation into your build environment. Those attacks compromised legitimate packages and used stolen credentials to spread to other packages.

He Who Controls the Dependencies Controls the Build

Every dependency adds more code to trust, more vulnerabilities to monitor, and more updates to manage. This doesn't mean "never use dependencies" or "always re-invent the wheel". We'd all still be writing our own HTTP clients and arguing about JSON parsers. It means minimize them.

When you do need a dependency, consider who maintains it and how much trust you're giving it. For .NET developers, something like Microsoft's Microsoft.FeatureManagement is a very different proposition from grabbing an obscure package maintained by someone with an unpronounceable alias. Microsoft isn't magically immune to vulnerabilities. No one is. But established vendors with mature security practices, release processes, and large communities can be a more comfortable place to put your trust.

The Spice Must Flow. Your Dependencies Don't Have To

Don't blindly consume latest. Pin dependencies to specific versions. Keep lock files under source control. Update deliberately. Review dependency changes instead of letting the package manager summon whatever happens to be waiting in the desert.

Remove dependencies you don't actually need.
Audit direct and transitive dependencies.
Monitor for known vulnerabilities.
Use trusted package sources.
Verify package provenance and signatures where available.
Keep CI/CD credentials locked down.
Give build processes only the permissions they actually need.
Treat unexpected dependency updates as something worth investigating.

Yes, We're a Dependency Too

FeatureFlags.app is a third-party dependency. We know. The irony is not lost on us. That's why the client library is intentionally small and open source. You can inspect it yourself - FeatureFlags.Client on GitHub.

The goal isn't to eliminate every dependency. The goal is to understand what you're trusting and keep that trust as small as practical.

Walk without rhythm and maybe the worm won't find you.

DEV Community: AvlCodeMonkey Industries

Build vs Buy: You Don't Need Another Side Project

When Configuration Becomes a Product

But AI Makes Building It Easy... Right?

Build vs Buy Isn't About Code

So... Build or Buy?

Microsoft Feature Management Quirks (and How to Survive Them)

Your Flag Names Are Strings Forever

The Fix

Configuration Shape Is Less Forgiving Than It Looks

The Fix

Filter Behavior Depends on Context Quality

The Fix

IsEnabledAsync Everywhere Means You Can Re-Evaluate a Lot

The Fix

IFeatureManager vs. IFeatureManagerSnapshot

The Fix

None of This Is a Dealbreaker

Cleaning Up Feature Flags: The Art of Not Leaving a Mess

Why Cleanup Matters

Track Every Flag

Set Expiry Dates

Make Cleanup Part of the Process

How to Actually Remove a Flag

The Goal

Feature Flags and Testing: Because QA Deserves Surprises Too

The State Explosion Problem

Test Every State of Every Flag

Test the Flag Infrastructure

Automate Everything

Document Expected Behavior

The Point

Implementing Feature Management in .NET: The Lazy Way

Installation

Configuration

Checking a Flag in Code

Using Feature Filters

Razor Tag Helpers

The Lazy Way Is Often the Right Way

Feature Flags and Continuous Delivery: Ship It Like You Mean It

The Core Problem: Deployment vs. Release

Test in Production (Carefully)

Instant Rollback Without a Redeployment

Trunk-Based Development

What This Looks Like in Practice

The Point

Feature Flag Pitfalls: How to Turn Your Codebase Into a Haunted House

Zombie Flags

The fix

Flag Explosion

The fix

Testing Complexity

The fix

Missing Documentation

The Bottom Line

Feature Flags in the Real World: Use Cases That Won't Get You Fired

Canary Releases

A/B Testing

Kill Switches

Beta Testing and Early Access

Dark Launches

The Point

Unlocking the Power of Feature Flags

What Are Feature Flags?

Why Use Feature Flags?

How Do Feature Flags Work?

The Code Monkey's Caution

Conclusion

Fear Is the Mind-Killer. Dependencies Are the Build-Killer

He Who Controls the Dependencies Controls the Build

The Spice Must Flow. Your Dependencies Don't Have To

Yes, We're a Dependency Too

`IsEnabledAsync` Everywhere Means You Can Re-Evaluate a Lot

`IFeatureManager` vs. `IFeatureManagerSnapshot`