How Atono’s feature flags empower fast development

Feature flags are one of the most powerful tools in a product team’s toolkit. They make it possible to ship code quickly, test ideas safely, and keep production stable. But not every type of flag serves the same purpose—or the same people. When a single tool tries to cover them all, it often slows teams down instead of speeding them up.

The clearest framework I’ve seen comes from Pete Hodgson’s seminal article Feature Toggles (aka Feature Flags). His four categories—Release, Experiment, Operations, and Permission—map to different roles in a company and have become so widely adopted that many vendors tailor their offerings to support them. This framework is also a useful way to explain the choices we made at Atono.

But here's what we've observed: when teams try to manage all four types in one system, they either pay for expensive standalone services or create coordination bottlenecks between teams. We built Atono differently. By focusing on the flags product teams actually use daily—Release and Experiment—we integrate them directly into your development workflow instead of requiring another separate tool.

Before diving into our approach, it's worth briefly explaining Hodgson's categories:

• Release flags help teams deploy incomplete features safely and control rollouts.

• Experiment flags enable A/B testing and gradual feature validation.

• Operations flags provide production safety controls like kill switches and performance tuning.

• Permission flags manage customer entitlements and feature access based on contracts.

Each serves different people, has different lifecycles, and requires different management approaches.

At Atono, we deliberately focused on the types of flags that work best for small, fast-moving, cross-functional teams. To improve the experience of using feature flags, we prioritized reducing the friction of managing them. That meant leaving out Operation and Permission flags and focusing on the ones product teams rely on most: Release and Experiment flags.

In this article, I’ll explore the tradeoffs of trying to support all four types and how our approach empowers smaller, fast-moving, cross-functional teams instead of getting in the way of their progress.

Conventional wisdom says feature flags should be temporary. But some—like those tied to production safety or customer contracts—are intentionally long-lived. What makes these flags different isn’t just their lifespan, but the fact that they’re controlled by different people.

That distinction shapes how each type of flag is used, who needs access to it, and whether it belongs in your development workflow at all. At Atono, we’ve focused on the flags that product teams manage themselves because keeping those in the development workflow is what helps teams operate quickly and with reduced risk.

Let's take a closer look.

Release and Experiment flags are primarily for PMs and development teams. Product teams use them to support fast, iterative development. These flags are expected to be removed once a feature is complete or an experiment ends. The development team and its PM know when a feature is ready to roll out.

QA may want to enable a feature early in their test environment to begin verification. Developers often turn them on locally while they’re building, and PMs may use them to share demos. The more integrated these flags are with the development lifecycle, the better. Using a separate system—or needing to ask someone else to flip a flag—quickly becomes a bottleneck.

Operations flags are used by operations engineers (who are sometimes developers), primarily to support or safeguard production systems. These include kill switches that disconnect unstable sub-systems, flags that switch rate-limiting strategies under heavy load, and flags that increase the logging level to help troubleshoot problems.

Some are temporary, but many are long-lived, because they’re critical to keeping the application running smoothly in production. Access to these flags should be limited to people responsible for production operations. That’s why it makes sense to isolate them in a separate system—away from the broader development team.

Permission flags (sometimes called entitlement flags) are typically used by Client Success or account teams. They control which features are enabled for which customers based on contracts or entitlement. They're usually permanent flags and managed per customer or customer group.

At Atono, we believe the account management system should be the authority for these configurations—not the feature flag system. This keeps responsibility clear and reduces the number of tools that non-technical teams need to use.

One last characteristic of Operation and Permission flags is that they often can’t have sensible in-code defaults.

For example, a permission flag that controls access to a contracted feature can’t default to ‘off’ without breaking the agreement, and can’t default to ‘on’ without over-delivering. Likewise, an operation flag such as a kill switch can’t safely default either way: set to ‘on,’ it could take down healthy systems; set to ‘off,’ it could leave a faulty service running.

I’ve encountered development teams who refused to use flags that were controlled externally from their applications because of this risk. There’s always a possibility—however small—that the application won’t be able to fetch the flag configuration from the remote service.

Our SDK uses multiple techniques to be resilient when flags do have reasonable defaults. For example, flag configurations are cached once retrieved from the API, so evaluations remain fast and consistent even if the API is temporarily unreachable. In-code defaults are only used as our last line of defense, making the whole strategy fail-safe.

But the challenge with Operations and Permission flags is that no safe default exists in the first place—so even this kind of resilience can’t resolve the risk.

Sometimes, teams that rely heavily on Operation and Permission flags conclude that they can’t afford to separate their management from the codebase. Or, if they adopt an external feature management tool, they’ll usually spend time and resources on infrastructure that replicates the feature configurations in their network so that they never have to fall back on in-code defaults.

Companies that offer "feature flag as a service" and aim to handle all these types of flags inherently become bottlenecks. This happens because Release, Experiment, Operations, and Permission flags are typically managed by different groups within an organization. In the end, these feature management services have to compromise to meet the different needs of development teams, operations, and Client Services.

It’s like how companies use different software for HR and sales: both manage people, but the roles, workflows, and responsibilities are completely different. The same applies to feature flags. Even though they all toggle behavior, the people using them, and the context in which they’re used are vastly different.

At Atono, we believe that these groups deserve tools that are suited specifically to their needs. By optimizing for the experience of product teams—where developers and PMs work closely together—we’re able to make using feature flags something teams embrace, rather than treat as a burden.