FeatureFlags.app

One thing I've intentionally done with FeatureFlags.app is keep the UI simple. There are feature flag platforms with enough knobs, switches, targeting rules, analytics, experimentation tools, dashboards, and configuration options to qualify as a small enterprise ERP system. And that's great... if you need all of that. But most teams don't.

If you're a .NET team that mostly needs to:

• Turn features on and off

• Roll features out gradually

• Target a few users

• Manage different environments

• Disable something without redeploying

... you probably don't need 47 configuration screens to accomplish it.

FeatureFlags.app is built around that idea: give developers the feature flag functionality they actually need without making them learn an entire feature management platform.

It integrates with Microsoft's Feature Management libraries, so the application side stays familiar. The UI handles the configuration without making you wrestle with JSON files or build a feature flag PhD. I'm deliberately leaving some of the bells and whistles on the shelf. Because sometimes the best feature is not having 37 features you don't need.

That's the philosophy behind FeatureFlags.app.

Microsoft's FeatureManagement makes adding feature flags to a .NET app ridiculously easy. A few flags in `appSettings.json and you're done.

Until you're not. Eventually you need non-technical people to manage flags, multiple environments, targeting, auditing, and changes without redeploying the app. AI makes building all of that easier too. But it doesn't make maintenance, hosting, security, monitoring, or future-you debugging your brilliant architecture free.

For a simple app with a few flags, build it. For everything else, maybe buy the plumbing. That's why I built FeatureFlags.app. 🚩

The recent Shai-Hulud npm supply-chain attack is a good reminder that every dependency is something you're trusting with your code, your build, and potentially your credentials. The answer isn't "never use dependencies." That's silly. We'd all still be writing our own HTTP clients.

Instead:

• Minimize dependencies.

• Pin them to specific versions.

• Audit direct and transitive dependencies.

• Remove packages you don't need.

• Use trusted package sources.

• Keep CI/CD credentials locked down.

And yes, FeatureFlags.app is itself a third-party dependency. We're not pretending otherwise. That's why the client library is intentionally small and open source, so you can actually see what you're putting into your application.

I realized something while working on FeatureFlags.app. Somewhere along the way, every developer tool decided it needed analytics, session replays, and enough tracking to write a biography of your users. So I went the other direction.

FeatureFlags.app doesn't include analytics or session replays. It doesn't track your users because... it doesn't need to. It's a feature flag service, not a surveillance platform.

My philosophy is simple: collect the minimum amount of data necessary to do the job. Less data means less risk, fewer privacy concerns, and fewer things to secure.

It feels weird that "we don't track your users" has become a feature worth announcing, but here we are.

This week's AWS billing glitch had developers waking up to invoices in the billions—and even trillions—of dollars. Thankfully it was just a bug, but it perfectly illustrates something I've never liked about usage-based pricing.

When I built FeatureFlags.app, I made one decision early: flat-rate pricing. No pricing calculators. No surprise invoices. No wondering if your bill is going to double next month.

I want customers thinking about shipping software, not watching a billing dashboard like it's the stock market. Cloud infrastructure is complicated enough. Your SaaS pricing doesn't have to be.

Sometimes boring is the best feature.

In the long long ago, before the great AI wars, SEO was easier. People submitted sitemaps to search engines (there were lots of them back then). And there were these things called directories where people could submit sites - and other people could find them. I'm looking at you Yahoo. Those days are long gone though.

I'm trying to figure out how to generate traffic these days, and it's not easy. Google and Bing are the only places to submit a sitemap anymore. No guarantee they'll choose to index your content though. Directories don't exist - unless you count the thousand different "product launch" sites that want to charge $40 for a backlink. Maybe there's a secret to it, maybe I'll find it. But I kinda miss the long long ago.

After getting laid off, I decided to try my hand at launching my own business instead of always making products for other folks. FeatureFlags.app fits a need that I've personally seen. Feature flags are used everywhere, and feature management is built into .Net. But Azure is really the only game if you want a UI for managing those features. So I decided to create something for small organizations and indie devs that don't want to deal with Azure.

It's my first product launch - fingers crossed - but it'll probably be bumpy. If you're looking for a feature flag solution, give it a try. And I'll keep sharing the bumps.