The fastest engineering teams in the world share a common pattern: they deploy code to production multiple times per day, but they do not release features to users at that same pace. The mechanism that makes this possible is feature flags.
A feature flag is a conditional check in your code that determines whether a feature is active for a given user. The feature is deployed (the code is in production) but it is not released (users do not see it yet). This separation between deployment and release is one of the most impactful architectural decisions a growing product team can make.
Feature flags are not just a developer convenience. They are a risk management tool that changes how your entire team ships software. Product managers can control rollouts without engineering support. Support teams can disable a problematic feature without a code deployment. And engineers can merge code to the main branch daily without worrying about incomplete features reaching users.
Why This Matters for Your Product
Without feature flags, your deployment pipeline looks like this: develop the feature, merge it to the main branch, deploy to staging, test, deploy to production. If something goes wrong, you either roll back the entire deployment (reverting every change, not just the broken one) or you rush a hotfix.
With feature flags, the pipeline changes: develop the feature behind a flag, merge it to the main branch (flag off), deploy to production (feature invisible), turn on the flag for internal users, test in production, gradually roll out to real users, monitor, and reach full rollout. If something goes wrong, you flip the flag off. No deployment required. No other features affected. The rollback is instant and surgical.
This pattern eliminates the most dangerous moment in software delivery: the production deployment that changes user facing behavior. Your CI/CD pipeline becomes simpler because every deployment is low risk. The code is already in production. You are just changing configuration.
The Architecture
A feature flag system has three components: the flag store, the evaluation engine, and the management interface.
The Flag Store
Flags need to be stored somewhere your application can access them quickly. The two common approaches:
Database backed flags store flag configuration in your application database. This is the simplest approach and works well for products with moderate traffic. Your application queries the flags table (with aggressive caching) and evaluates the rules locally. The advantage is no external dependency. The disadvantage is that you need to build the caching and invalidation yourself.
Dedicated flag service is a separate service (or managed product) that your application queries for flag evaluations. This is the better architecture at scale because it separates flag evaluation from your main application, supports real time flag updates without cache invalidation, and provides a purpose built management interface.
For most products we build at Veld through our full stack development service, we start with database backed flags and migrate to a dedicated service when the number of flags or the evaluation complexity warrants it.
The Evaluation Engine
The evaluation engine is where the decision logic lives. A flag evaluation takes the current user context (user ID, role, organization, plan tier, geographic location) and the flag configuration (rules, percentages, targeting) and returns a boolean or a variant.
Simple boolean flags are on or off. "Is the new dashboard enabled?" This is where every team starts.
Percentage rollouts enable the feature for a percentage of users. "Enable the new checkout flow for 10% of users." The critical implementation detail is that the percentage must be deterministic, meaning the same user gets the same result every time. Hash the user ID with the flag name to produce a stable assignment. Do not use random numbers, or the same user will see the feature appear and disappear randomly.
Targeted rollouts enable the feature for specific segments. "Enable the new reporting module for enterprise tier customers" or "enable the redesigned onboarding for users who signed up after February 1." This requires your evaluation engine to understand user attributes and match them against flag targeting rules.
Multivariate flags return one of several variants, not just on/off. This is how you run A/B tests behind feature flags. "Show variant A (blue button) to 50% of users and variant B (green button) to the other 50%."
The Management Interface
Engineers should not need to edit database records or deploy config files to manage flags. Build or use a management interface that lets your team:
- Create and configure flags with targeting rules
- View the current state of every flag
- See which users or segments are targeted
- View flag evaluation history and audit logs
- Toggle flags instantly with a confirmation step
The management interface is what makes feature flags a team tool rather than just a developer tool. Product managers can control rollouts. Support teams can emergency disable features. Leadership can see what is being tested and what is live.
Patterns That Work
Trunk Based Development
Feature flags enable trunk based development, where every engineer commits to the main branch daily. Long lived feature branches are one of the biggest sources of merge conflicts, integration bugs, and delayed feedback. When every feature is behind a flag, there is no reason to maintain a separate branch for weeks.
The code goes into main behind a disabled flag. Other engineers can see it, review it, and even test it. When it is ready, the flag turns on. This dramatically reduces integration risk and aligns well with the deployment practices we outline in our CI/CD pipeline guide.
Operational Kill Switches
Not every flag is for new features. Some of the most valuable flags are operational kill switches that let you degrade gracefully under load.
For example, a flag that disables non essential background processing during peak traffic. Or a flag that switches from real time search to cached search results when your search cluster is under pressure. Or a flag that disables third party integrations when a vendor's API is having issues.
These flags are not about features. They are about operational resilience. They give your team levers to pull when things go wrong without deploying code, which in terms of cloud infrastructure management is invaluable.
Entitlement Flags
Feature flags are natural for managing plan based feature access. Instead of hardcoding "if user plan is enterprise, show analytics dashboard," you use a flag that is targeted to enterprise tier users. When you want to give a specific customer early access to a feature, you add them to the flag's targeting rules instead of changing code.
This decouples your billing tiers from your codebase. When the pricing changes (and it will), you update flag targeting rules instead of deploying code changes. This approach pairs well with the architecture decisions discussed in our SaaS product guide.
The Mistakes That Hurt
Flag Debt
The biggest risk with feature flags is accumulation. Every flag you create is a conditional branch in your code. Over time, flags that are fully rolled out (100% on for months) become dead code paths. The "off" branch will never run, but it still exists in your codebase, making the code harder to read and maintain.
Establish a lifecycle for every flag. When you create a flag, set an expected cleanup date. When the flag has been at 100% for two weeks with no issues, remove the flag and the old code path. This is not optional housekeeping. It is essential maintenance, similar in principle to the ongoing work we describe in our ongoing management service.
Testing Complexity
Every feature flag doubles the number of possible states in your application. Two flags create four states. Ten flags create 1,024 states. You cannot test every combination.
The practical approach: test the default state (all flags off), test each flag independently in its on state, and test known combinations that interact with each other. Do not try to test every permutation. Instead, invest in monitoring so you catch unexpected interactions in production.
Stale Targeting Rules
Flags targeted to specific users or segments can become stale. A flag targeted to "users in the beta program" stops making sense when the beta program ends. Review targeting rules regularly and clean up flags that no longer have a clear purpose.
Build vs. Buy
For teams with fewer than 20 flags that are primarily boolean kill switches, a database table with a simple admin UI is sufficient. You can build this in a day.
For teams that need percentage rollouts, multivariate testing, targeting rules, and audit logs, the build vs. buy calculation shifts. Building a full featured flag evaluation engine with a management interface, real time updates, and proper SDKs is weeks of work. Managed services handle this well, and the cost is typically modest relative to the engineering time saved.
Our recommendation: start with a simple in house implementation and migrate to a managed service when flag complexity outgrows what you built. The most important thing is to use flags at all, not which tool you use to manage them.
Getting Started
If you are not using feature flags today, start with one. Pick the next feature your team is building, put it behind a flag, deploy it to production with the flag off, and then turn it on when you are ready. Experience the workflow once and you will never want to ship without flags again.
If you are building a product and want feature flags wired into your architecture from the start, reach out to us. We will design a flag system that fits your team's workflow and your product's requirements.