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.
Top comments (0)