DEV Community: Scott

Compile-time feature flags in C# using IL weaving and a Roslyn analyzer

Scott — Tue, 23 Jun 2026 18:26:49 +0000

I got fed up of writing this everywhere:

if (await _featureManager.IsEnabledAsync("SendWelcomeEmail"))
{
    await SendWelcomeEmailAsync(user);
}

Not because it's hard. Because it's noise. It's the same pattern, over and over, scattered through every service, every controller, every background job. The feature logic and the gating logic tangled together forever. Magic strings that can drift. Call sites to hunt down when you finally retire the flag. It's boring and it's everywhere and I decided to do something about it that probably shouldn't work but does.

The problem: two things that shouldn't be your problem

1. The if statement noise

Every feature flag adds ceremony at every call site. Multiply that across a real codebase and you've got if statements in places they have no business being. When the flag is retired you have to find every single one manually. And if you mistype the string key? Silent failure. Great.

2. No compile-time safety

String keys are the lingua franca of feature flag libraries. "SendWelcomeEmail", "new-checkout-flow", "payment_v2": magic strings the compiler can't validate, that can be mistyped, that go stale when you rename a method, that give you absolutely no indication at build time that anything is wrong.

Architectural decision 1: the method IS the feature

The first thing I decided: [Toggle] should be the only thing you need to add to ship a feature dark, and the only thing you need to remove to retire it.

So instead of wrapping every call site in an if block, you decorate the method:

[Toggle]
public void SendWelcomeEmail(User user)
{
    // send the email
}

Then call it normally:

SendWelcomeEmail(user); // only executes if "SendWelcomeEmail": true in appsettings.json

No if. No injected service at the call site. No magic string. The method name is the toggle key.

When you want to retire the flag, you remove [Toggle]. That's it. There are no call sites to update because there were never any call sites wrapping the feature. The method goes back to being a normal method.

One attribute to ship dark. One attribute removal to retire. Nothing else changes.

For async methods:

[ToggleAsync]
public async Task SendWelcomeEmailAsync(User user)
{
    await _emailClient.SendAsync(user.Email);
}

await SendWelcomeEmailAsync(user); // safely awaitable whether on or off

When the toggle is off, [ToggleAsync] returns Task.CompletedTask; always safely awaitable, no null reference risk.

Architectural decision 2: radical ownership

The second decision: your flag data lives with your app.

FtrIO is built around you owning your flag state. Not as a fallback, not as an offline mode: as the primary design. Your flag state lives in appsettings.json, alongside your application code, on your server, in your repository. It is a first-class citizen of your app, not a remote dependency.

If you use a remote provider, it runs in the background, polls for changes, and writes the updated state into your local file via an atomic buffer. The read path always reads from your file.

Remote provider         ToggleProviderBuffer        appsettings.json
(HTTP / Azure /    →    (stages changes,        →   (source of truth,
 env vars)              flushes atomically)          always yours)
                                                          ↓
                                                     [Toggle] method
                                                     (reads at call time)

Your flag state is a text file sitting next to your code. Open it and you can see exactly what every toggle is set to. Edit it in an emergency and ReloadOnChange picks it up with no restart. Diff it in git, deploy it with your app, take it with you if you ever change tooling.

Remote providers are optional, not foundational. Remove them and appsettings.json is still your fully functional flag store. The call sites don't change either way.

How IL weaving makes decision 1 possible

Here's where it gets interesting.

[Toggle] is an aspect powered by AspectInjector, a compile-time IL weaving library. When you build your project, AspectInjector walks the compiled IL, finds every method decorated with [Toggle], and weaves a gate check directly into the method's IL, before the method body executes.

The gate reads the toggle state from ToggleParser, which reads from appsettings.json. If the toggle is off, the method returns immediately. If it's on, the method body executes as normal.

The weaving happens at compile time. At runtime there is no reflection, no proxy, no dynamic invocation; just a direct IL call. The method behaves identically to a method that was always written with the gate logic inline, except you didn't have to write it.

You can see exactly what AspectInjector wove into your method using Rider's IL Viewer — Tools → IL Viewer. It's not magic. It's just IL. And it's right there for you to inspect.

This is also why removing the attribute is a clean operation. There is no call site to update. The aspect is gone from the IL, the gate is gone, and the method is back to normal behaviour.

Roslyn closes the loop

IL weaving handles the syntax. But what about the case where you decorate a method with [Toggle] and forget to add the corresponding entry to appsettings.json?

Without anything else, that's a silent runtime failure; the toggle evaluates as missing and the feature quietly does not run. That's not good enough.

So I built a Roslyn analyzer, FTRIO001, that catches this at build time.

Add appsettings.json as an AdditionalFile in your .csproj:

<ItemGroup>
  <AdditionalFiles Include="appsettings.json" />
</ItemGroup>

Now if you write this:

[Toggle]
public void NewCheckoutFlow() { ... }

Without adding "NewCheckoutFlow" to your Toggles section, the build fails:

error FTRIO001: 'NewCheckoutFlow' is decorated with [Toggle]
but has no corresponding entry in the Toggles config section.

The compiler validates the contract between your code and your config. Magic string drift is caught before it ever reaches a running application. Rider surfaces FTRIO001 inline as you type — no plugin required.

Strategies: honestly an afterthought

Honestly? This whole section was an afterthought.

When I first started this project years ago, I only ever expected features to run or not run. On or off. That was the whole mental model. I put it down for a long time, picked it up again with fresh eyes, and realised the world is a bit more nuanced than that. Percentage rollouts. Blue-green deployments. A/B tests. Per-user targeting. These are real things real teams need.

So I added them. But I want to be clear about what they are: add-ons that all ultimately boil down to the same question. Should this method execute or not? The strategies are just different ways of answering it. The call site never changes.

I'm genuinely excited about where this goes next. The foundation is solid and there's a lot of interesting territory still to explore. But the core idea — one attribute, run or not run — is still what drives everything.

FtrIO's StrategyToggleParser routes raw config values through a chain of IToggleDecisionStrategy implementations, with BooleanStrategy always appended as the final fallback.

{
  "Toggles": {
    "NewCheckoutFlow":   "20%",
    "PaymentV2":         "blue",
    "BetaFeature":       "users:alice,bob",
    "PremiumDashboard":  "attribute:plan equals premium",
    "Experiment":        "ab:50"
  }
}

ToggleParserProvider.Configure(new StrategyToggleParser(
    new UserTargetingStrategy(accessor),
    new AttributeRuleStrategy(accessor),
    new ABTestStrategy(accessor),
    new PercentageRolloutStrategy(),
    new BlueGreenStrategy("blue", "blue", "green")
));

Each strategy implements CanHandle(string rawValue) and ShouldExecute(string key, string rawValue). The parser tries each in order; first match wins, BooleanStrategy catches everything else.

PercentageRolloutStrategy handles "20%": probabilistic, runs approximately 1 in 5 calls.

BlueGreenStrategy handles "blue" / "green": compares the config value to the current deployment slot.

UserTargetingStrategy handles "users:alice,bob": checks the current user ID against a comma-separated allow list via IFtrIOContextAccessor.

AttributeRuleStrategy handles "attribute:plan equals premium": evaluates an attribute rule against the current user context. Supports equals, notEquals, startsWith, endsWith, contains, in, notIn.

ABTestStrategy handles "ab:50": deterministic bucketing via SHA-256 of the user ID and toggle key, mod 100. The same user always gets the same result for a given toggle. Salt support ("ab:50:round2") allows population reassignment without changing the toggle key.

All of this is driven by the value in appsettings.json. The call site is always the same:

[Toggle]
public void NewCheckoutFlow() { ... }

The strategy chain is wired up once at startup. The config value determines which strategy fires. The [Toggle] attribute knows nothing about strategies.

The rest of the ecosystem

The library is the core but it's not the whole thing.

FtrIO.Toaster is a self-hosted Docker web UI for managing toggles live. It implements FtrIO's own ToggleProviderBuffer internally; changes flush atomically to appsettings.json and your app picks them up via ReloadOnChange with no restart. Boolean, percentage, blue-green, per-user targeting, A/B test salts, per-user overrides — all manageable from the UI.

FtrIO.onetwo is a .NET CLI audit tool. Scans your source tree, cross-references against appsettings.json, and reports the state of each toggle: ON, OFF, 20%, BLUE, AB-TEST(50%), TARGETED(alice,bob), MISSING, with file and line number. Also has experimental subcommands for importing flag state from LaunchDarkly, Flagsmith, and Microsoft.FeatureManagement, generating migration reports, and ejecting back out to another system.

export-manifest-action and release-check-action are GitHub Actions that together gate deployments on missing toggle config. The full safety net:

Stage	What catches it
Write `[Toggle]` without config	Roslyn analyzer: compile time
Deploy with key missing from target env	`release-check-action`: deploy time

Getting started

dotnet add package FtrIO

<PackageReference Include="AspectInjector" Version="2.9.0" />

{
  "FtrIO": { "ReloadOnChange": true },
  "Toggles": {
    "SendWelcomeEmail": true,
    "NewCheckoutFlow": false
  }
}

[Toggle]
public void SendWelcomeEmail() { ... }

SendWelcomeEmail(); // runs only if "SendWelcomeEmail": true

Everything else is opt-in. Toaster when you want a UI. onetwo when you want audit tooling. Strategies when you need targeting. GitHub Actions when you want deployment safety. You never need all of it.

There's a lot more you can do with IL weaving and Roslyn than people realise. I built a feature flag library with it. What are you going to build?

Already using LaunchDarkly or Flagsmith? Here's how to try FtrIO on a single flag

Scott — Sun, 21 Jun 2026 18:44:13 +0000

Thinking about trying FtrIO? The new CLI makes it easy to start with just one feature flag

If you've been curious about FtrIO (the .NET feature toggle library that replaces if (featureFlags.IsEnabled(...)) with a [Toggle] attribute woven directly into your compiled IL) but weren't sure where to start, the experimental release of FtrIO.onetwo just made that first step a lot smaller.

You don't need to commit to a full migration. You don't need to rip out your existing flag library. You just need one method and 20 minutes.

What FtrIO.onetwo does

FtrIO.onetwo is a .NET CLI audit tool. Its default mode scans your source tree, finds every FtrIO toggle reference, and tells you exactly what's live right now:

dotnet tool install --global FtrIO.onetwo --version 1.1.1-experimental
ftrio.onetwo --source C:\Projects\MyApp

But in this experimental release it does two new things:

ftrio.onetwo import: pulls your current flag state from LaunchDarkly, Flagsmith, flagd, environment variables, or an HTTP endpoint directly into appsettings.json. Your existing flag library keeps working unchanged.

ftrio.onetwo migrate: scans your .cs files for LaunchDarkly or Flagsmith SDK call patterns using Roslyn, cross-references them against your live flag state, and generates a report showing exactly what each flag would look like in FtrIO and how to migrate it.

The "try it on one flag" workflow

The migrate report categorises every flag it finds:

✅ Ready to migrate: boolean flag, no targeting rules, straightforward [Toggle] replacement
⚠️ Needs review: targeting rules, number flags, needs a decision
❌ Cannot migrate: JSON flags, recommend moving to IConfiguration

For every ready flag it shows the suggested refactor. Something like:

new-checkout-flow → NewCheckoutFlow
File: Services\OrderService.cs:42

Current code:
  if (client.BoolVariation("new-checkout-flow", user, false))
  {
      ValidateCart();
      ApplyDiscounts();
      ProcessPayment();
  }

Suggested action:
  Extract the if block into a parent method named NewCheckoutFlow,
  then decorate it with [Toggle]. The inner methods remain unchanged.

  [Toggle]
  public void NewCheckoutFlow()
  {
      ValidateCart();
      ApplyDiscounts();
      ProcessPayment();
  }

  Add to appsettings.json:
  "NewCheckoutFlow": false

Pick one of those ready flags. Do the refactor. Run the app. That's it: you've got FtrIO running in your codebase alongside your existing flag library, on exactly one feature, with everything else completely unchanged.

If you like how it feels, pick another. If you don't, remove the [Toggle] attribute and you're back to where you started.

Why the parent method suggestion matters

The report nudges toward a pattern that's worth calling out explicitly: one named parent method per toggled feature.

Instead of this:

if (client.BoolVariation("send-welcome-email", user, false))
{
    ValidateEmailAddress(user.Email);
    BuildEmailTemplate(user);
    SendViaSmtp(user.Email);
    LogEmailSent(user.Id);
}

FtrIO works best like this:

[Toggle]
public void SendWelcomeEmail()
{
    ValidateEmailAddress(_user.Email);
    BuildEmailTemplate(_user);
    SendViaSmtp(_user.Email);
    LogEmailSent(_user.Id);
}

The feature has a single, named, discoverable entry point. The toggle is a gate on the feature, not scattered through its implementation. The inner methods have no idea a toggle exists. This is better code regardless of FtrIO; the migration report teaches the pattern rather than just doing a mechanical find-and-replace.

Running the migration report

# With live flag state from LaunchDarkly
ftrio.onetwo migrate \
  --from launchdarkly \
  --api-key sdk-xxx \
  --project my-project \
  --env production \
  --source C:\Projects\MyApp \
  --markdown plan.md

# Code scan only, no API key needed
ftrio.onetwo migrate \
  --from launchdarkly \
  --source C:\Projects\MyApp

The --api-key is optional; without it the report still finds all your call sites and shows the suggested refactors, just with placeholder values in the appsettings.json snippets instead of live flag states.

This is experimental

Both import and migrate are in an experimental branch. To try it you need to explicitly request the experimental version — the default install will give you the stable release which doesn't include these commands yet:

dotnet tool install --global FtrIO.onetwo --version 1.1.1-experimental

Functional but not yet on a stable release. Feedback is genuinely welcome, especially on the migration report format and the flag mapping logic.

The full FtrIO ecosystem:

FtrIO: the core library: dotnet add package FtrIO
FtrIO.Toaster: self-hosted Docker UI for managing toggles live
FtrIO.onetwo: this CLI: dotnet tool install -g FtrIO.onetwo
Docs: ftronoff.github.io/FtrIO
GitHub: github.com/FtrOnOff

If you try it on a flag or two I'd love to hear how it goes; drop a comment or open an issue.

I got tired of writing ifs everywhere — so I built an ecosystem

Scott — Sun, 21 Jun 2026 14:46:02 +0000

I got tired of writing `if (featureFlags.IsEnabled(...))` everywhere — so I built an ecosystem

I've been writing C# for over a decade and feature flags have always annoyed me in the same way.

Not the concept — the concept is great. The ability to ship code dark, roll out to a percentage of traffic, or flip a switch without a redeploy is genuinely powerful. What annoyed me was the noise. Every time I added a feature flag I'd end up with this scattered through the codebase:

if (featureFlags.IsEnabled("SendWelcomeEmail"))
{
    SendWelcomeEmail();
}

Multiply that across a real codebase and you've got if statements everywhere, magic strings that drift out of sync with config, and no easy way to know what's actually live at any given moment without opening files manually.

So I built something about it. Then I built something else. Then I hadn't slept and had consumed several root beers and I had an ecosystem.

The problem with feature flags in .NET

Most feature flag libraries for .NET — including Microsoft's own Microsoft.FeatureManagement — solve the storage and evaluation problem well. But they don't solve the noise problem. You still have to wrap every call site, inject a service everywhere, and remember to clean up the if statements when a flag is retired.

LaunchDarkly and Flagsmith go further with SaaS dashboards and targeting rules, but now you've got a vendor dependency, a network call on your hot path, and a subscription fee.

What I wanted was something that felt like a natural part of the language — where toggling a feature on or off was as simple as adding or removing an attribute, and the checking happened automatically without touching every call site.

FtrIO — the core library

The idea behind FtrIO is simple: decorate a method with [Toggle] and it becomes config-gated by its own name.

[Toggle]
public void SendWelcomeEmail()
{
    // send the email
}

SendWelcomeEmail(); // only runs if "SendWelcomeEmail": true in appsettings.json

That's it. No if, no injected service, no wrapper. The method calls exactly like a normal method. If the toggle is off, it just doesn't run.

How it actually works

[Toggle] is an AspectInjector aspect. At compile time, AspectInjector weaves the gating check directly into the method's IL. The gate is applied at the IL level, so it works regardless of how the method is called — direct call, reflection, delegate, anything.

Config lives in appsettings.json:

{
  "Toggles": {
    "SendWelcomeEmail": true,
    "NewCheckoutFlow": false
  }
}

Compile-time validation

The thing I'm most proud of: FtrIO ships a Roslyn analyzer that catches missing config entries at build time.

If you decorate a method with [Toggle] but forget to add the matching entry to appsettings.json, the build fails with FTRIO001 — not a silent runtime failure, not a logged warning, a proper compiler error:

error FTRIO001: 'NewCheckoutFlow' is decorated with [Toggle] but has no entry in Toggles

No other feature flag library I know of does this, at any price.

Async support

For async methods, [ToggleAsync] returns Task.CompletedTask or Task.FromResult(default) when the toggle is off — always safely awaitable:

[ToggleAsync]
public async Task SendWelcomeEmailAsync()
{
    await emailClient.SendAsync(...);
}

await SendWelcomeEmailAsync(); // safely awaitable whether the toggle is on or off

Beyond true/false — strategy-based decisions

FtrIO isn't limited to boolean toggles. StrategyToggleParser routes raw config values through a chain of strategies:

{
  "Toggles": {
    "NewCheckout": "20%",
    "PaymentV2": "blue"
  }
}

ToggleParserProvider.Configure(new StrategyToggleParser(
    new PercentageRolloutStrategy(),      // "20%" runs ~1 in 5 calls
    new BlueGreenStrategy("blue", "blue", "green")  // runs only on the blue slot
));

Percentage rollouts, blue-green deployment switching, or any custom logic you implement via IToggleDecisionStrategy.

Dynamic providers

For toggle state driven by external sources — HTTP endpoints, Azure App Config, environment variables — FtrIO uses a provider pipeline that writes into appsettings.json in the background. The read path always comes from the file.

This means if a remote provider goes offline, the last known state serves automatically from disk. No fallback code, no circuit breaker, no stale-cache TTL to configure.

dotnet add package FtrIO.Providers.Http
dotnet add package FtrIO.Providers.AzureAppConfig

Installation

dotnet add package FtrIO

Targets .NET 6, 8, and 10.

FtrIO.Toaster — the management UI

Once FtrIO was in use, I had a new problem: flipping toggles meant editing appsettings.json by hand. Across multiple environments. That got old quickly.

So I built FtrIO.Toaster — a lightweight Dockerized web UI for managing toggles live.

The name has two origins: toast is binary (toasted or not, much like a feature toggle), and it's a nod to the Dungeon Master who runs our D&D sessions. Every good campaign needs someone deciding what's enabled and what isn't.

What it does

Boolean on/off toggles
Percentage rollout — slider and number input in sync
Blue/green deployment switching
Change toggle type at any time
Add and delete toggles
Multi-environment support — manage any number of environments from a single UI instance via a dropdown
Audit log — every change recorded with timestamp, environment, toggle key, old value, new value, and the acting user
Basic Auth built in, with an OAuth2 Proxy sidecar option for SSO (Google, GitHub, Microsoft, GitLab, OIDC)

How it fits with FtrIO core

Toaster implements FtrIO's own ToggleProviderBuffer internally. Changes are staged in memory and flushed atomically to appsettings.json on the configured interval — exactly as a native FtrIO provider would. Your running app picks up changes via ReloadOnChange with no restart.

Getting started

No clone required — pull from Docker Hub:

services:
  toaster:
    image: thescottbot/ftrio:latest
    ports:
      - "8000:8000"
    environment:
      APP_NAME: "My Application"
      APPSETTINGS_PATH: /data/appsettings.json
    volumes:
      - type: bind
        source: /path/to/your/appsettings.json
        target: /data/appsettings.json
    restart: unless-stopped

docker compose up -d

Open http://localhost:8000.

FtrIO.onetwo — the audit CLI

The third problem: as the codebase grew, there was no easy way to know what was actually live right now without opening appsettings.json and cross-referencing it with the source code manually.

FtrIO.onetwo is a .NET global tool that does that cross-referencing for you:

dotnet tool install -g FtrIO.onetwo
ftrio.onetwo --source C:\Projects\MyApp

It walks your source tree, finds every [Toggle], [ToggleAsync], and manual call, and outputs a table:

── Staging C:\Projects\MyApp\appsettings.Staging.json
╭──────────────────┬──────────────────┬────────────┬─────────┬───────────────────┬──────╮
│ Toggle Key       │ Method           │ Source     │  State  │ File              │ Line │
├──────────────────┼──────────────────┼────────────┼─────────┼───────────────────┼──────┤
│ NewCheckoutFlow  │ NewCheckoutFlow  │ [Toggle]   │   50%   │ Services\Order.cs │    9 │
│ PaymentV2        │ PaymentV2        │ [Toggle]   │  BLUE   │ Services\Pay.cs   │    6 │
│ SendWelcomeEmail │ SendWelcomeEmail │ [Toggle]   │   ON    │ Services\Email.cs │   22 │
│ UnknownFeature   │ UnknownFeature   │ ManualCall │ MISSING │ Controllers\Ho... │   42 │
╰──────────────────┴──────────────────┴────────────┴─────────┴───────────────────┴──────╯
4 toggle(s). 1 ON, 0 OFF, 1 PERCENTAGE, 1 BLUE/GREEN, 1 MISSING.

The MISSING state is the one I find most useful — it catches toggles that exist in code but have no config entry, across every environment, before they cause a silent runtime failure. No other feature flag tooling I know of does this.

Supports --env Staging to target a specific environment overlay, and --markdown to write the output to a markdown file for documentation or CI artefacts.

How they fit together

All three tools share appsettings.json as the single source of truth. No coupling between them — use any combination without changing your call sites:

┌─────────────────────────────────────────────────────┐
│  Your code                                          │
│  [Toggle] public void SendWelcomeEmail() { ... }    │
└───────────────────┬─────────────────────────────────┘
                    │ compile-time weaving
                    ▼
┌─────────────────────────────────────────────────────┐
│  FtrIO core                                         │
│  gates method execution at runtime                  │
└───────────────────┬─────────────────────────────────┘
                    │ reads
                    ▼
┌─────────────────────────────────────────────────────┐
│  appsettings.json  — source of truth                │
└──────────┬──────────────────────────┬───────────────┘
           │ writes live              │ reads & audits
           ▼                          ▼
  FtrIO.Toaster                 FtrIO.onetwo
  (web UI — manage toggles)     (CLI — audit state)

How it compares

	FtrIO	LaunchDarkly	Microsoft.FeatureManagement	Flagsmith
Call-site syntax	`[Toggle]` attribute, zero noise	SDK call at every site	`if (await _fm.IsEnabledAsync(...))`	SDK call at every site
Works offline	✅ always (file-backed)	❌ needs SDK fallback config	✅	❌ needs SDK fallback config
Compile-time validation	✅ Roslyn analyzer	❌	❌	❌
Codebase audit / drift detection	✅ onetwo CLI	❌	❌	❌
Management UI	✅ Toaster, self-hosted	✅ SaaS dashboard	❌	✅ SaaS dashboard
Percentage rollout	✅	✅	✅	✅
Self-hosted / no vendor	✅	❌ paid SaaS	✅	✅ (or SaaS)
Cost	Free, OSS	Paid SaaS	Free, OSS	Free tier / paid SaaS

Where to find it

Everything lives under the FtrOnOff org on GitHub:

FtrIO (core library) — dotnet add package FtrIO
FtrIO.Toaster (Docker UI) — docker compose up -d
FtrIO.onetwo (audit CLI) — dotnet tool install -g FtrIO.onetwo
Full docs — ftronoff.github.io/FtrIO

All free, all open source, all built on no sleep and root beer. 🍺

If you try it I'd love to know what you think — drop a comment or open an issue.

DEV Community: Scott

Compile-time feature flags in C# using IL weaving and a Roslyn analyzer

The problem: two things that shouldn't be your problem

1. The if statement noise

2. No compile-time safety

Architectural decision 1: the method IS the feature

Architectural decision 2: radical ownership

How IL weaving makes decision 1 possible

Roslyn closes the loop

Strategies: honestly an afterthought

The rest of the ecosystem

Getting started

Links

Already using LaunchDarkly or Flagsmith? Here's how to try FtrIO on a single flag

Thinking about trying FtrIO? The new CLI makes it easy to start with just one feature flag

What FtrIO.onetwo does

The "try it on one flag" workflow

Why the parent method suggestion matters

Running the migration report

This is experimental

I got tired of writing ifs everywhere — so I built an ecosystem

I got tired of writing if (featureFlags.IsEnabled(...)) everywhere — so I built an ecosystem

The problem with feature flags in .NET

FtrIO — the core library

How it actually works

Compile-time validation

Async support

Beyond true/false — strategy-based decisions

Dynamic providers

Installation

FtrIO.Toaster — the management UI

What it does

How it fits with FtrIO core

Getting started

FtrIO.onetwo — the audit CLI

How they fit together

How it compares

Where to find it

I got tired of writing `if (featureFlags.IsEnabled(...))` everywhere — so I built an ecosystem