In a previous post, I wrote about how feature flag tooling often grows beyond what small teams actually need — accumulating workflows, permissions, and pricing models designed primarily for large organizations.
This time, I want to focus on the opposite side of that conversation.
Instead of discussing what feature flag platforms add over time, I want to outline what we deliberately didn’t build when designing a feature flag service — and why those omissions matter just as much as the features themselves.
Reducing the surface area
One of the first decisions was to keep the surface area as small as possible.
That meant intentionally avoiding things like:
- multi-step approval workflows
- deeply nested permission models
- per-flag configuration matrices
- role hierarchies that change behaviour depending on context
Not because these features are inherently bad — but because they introduce operational decisions that many small teams simply don’t need to make.
For most day-to-day use cases, a feature flag answers a very simple question:
Is this on or off in this environment right now?
Anything that complicates that decision adds cognitive load, not clarity.
Keeping flag behaviour boring
Feature flags are an operational tool, not a delivery mechanism.
From a product perspective, teams shouldn’t have to think about how often flags refresh, when updates propagate, or what happens under the hood when a value changes.
What matters is much simpler:
- flag behaviour should be consistent
- changes should be reflected in a reasonable timeframe
- client-side behaviour should be predictable across environments
When teams start reasoning about update intervals, cache lifetimes, or synchronisation edge cases, feature flags stop being a tool and start becoming infrastructure.
We deliberately focused on keeping flag behaviour boring — no special cases, no platform-specific rules, no mental overhead around “how this works”.
How updates are delivered internally can evolve over time. The goal is to make sure teams don’t have to care.
Environment-aware flags
Most products operate across multiple environments:
development, staging, production, previews.
Environment isolation is important, but it doesn’t need to introduce additional configuration layers or separate workflows.
A single feature flag defines its values across environments.
Each environment has its own on/off state, while the flag itself remains the same.
At runtime, environments are fully isolated:
clients only ever receive values for the environment they’re configured for.
This keeps configuration explicit and predictable, without introducing additional rules or conditional logic.
Optimizing for day-to-day usage
A recurring theme in larger platforms is supporting every possible use case:
- long-lived experiments
- gradual rollouts
- user targeting
- analytics-driven decisions
Those are valid needs — but they’re not universal needs.
For many teams, feature flags are primarily used for:
- enabling or disabling incomplete features
- decoupling deployment from release
- quickly reacting to production issues
Optimizing for these day-to-day scenarios means saying no to features that only become relevant much later — if at all.
Where this led us
These constraints and decisions eventually became Feato — a simple feature flag management system focused on clarity rather than enterprise workflows.
The goal wasn’t to compete feature-for-feature with existing platforms, but to offer something that stays lightweight as long as the team itself is lightweight.
If you’re dealing with similar trade-offs — trying to keep operational overhead low while still retaining control over releases — this approach might resonate.
You can learn more here:
https://feato.io/
Top comments (0)