For most sub–Series B teams, the best alternative is a lightweight, custom feature flag system with local evaluation, clear targeting rules, and a simple rollout dashboard. Tools like LaunchDarkly are powerful, but their per-seat and usage pricing makes experimentation expensive. A focused internal system gives you control without the cost.
Why teams outgrow LaunchDarkly
Feature flags start simple.
Turn a feature on or off.
Ship safely.
But as teams grow:
flags multiply
environments increase
experiments expand
Pricing scales with:
seats
environments
usage
At ~10 engineers, the math changes.
You’re paying more for the tool
than the value it provides.
The 5 pieces of a real feature flag system
A proper system is not just a toggle.
You need:
Flag definitions
name, type, default value
Targeting rules
who sees what
Evaluation layer
decides flag value at runtime
Rollout dashboard
control and visibility
Audit log
track changes and history
Most teams only build the first one.
The other four are what make it usable.
Starter prompt
Instead of vague instructions, define the system clearly:
Build a feature flag system with flag definitions, targeting rules, local evaluation, rollout controls, and audit logging with support for percentage rollouts and user segmentation.
Clarity here avoids rebuilding later.
The performance constraint (critical)
This is the most important rule:
Flag evaluation must be local
Bad pattern:
API call on every flag check
Result:
latency
failures
cascading outages
Correct pattern:
fetch config once
evaluate in memory
This is how production systems scale.
SDK design patterns
You need different evaluation strategies depending on context.
Server-side evaluation
backend decides flag values
consistent and secure
Client-side evaluation
frontend evaluates using config
faster UX, less backend load
Edge evaluation
evaluate at CDN/edge layer
useful for global apps
Most systems combine these.
Targeting rule design
Flags become powerful when targeting is flexible.
Common patterns:
user attributes (plan, region)
segments (beta users, internal users)
percentage rollouts (10%, 50%, 100%)
Example:
enable feature for 20% of users in US on paid plan
The key is composability.
Avoid hardcoding logic.
Rollouts and safety
Feature flags are about controlled releases.
Good rollout flow:
start at 1%
monitor metrics
increase gradually
This reduces risk significantly.
Without this, flags lose their purpose.
A/B testing (most teams skip this)
Flags enable experiments.
But experiments need measurement.
Basic setup:
assign users to variants
track outcomes
compare metrics
Without analysis:
you are guessing
not experimenting
This is where most homegrown systems fall short.
Audit logging (don’t ignore this)
Every change should be tracked:
who changed a flag
when it changed
what the previous value was
This is essential for:
debugging
accountability
rollback
When building makes sense
You should build if:
team is small to mid-size
experimentation is frequent
pricing tools feel restrictive
you need flexibility
The goal is not to rebuild LaunchDarkly.
It is to build what you actually need.
When not to build
You should avoid building if:
you are in regulated industries
you need compliance-grade audit trails
you are a large org with complex workflows
In these cases, tools like LaunchDarkly still make sense.
Where structured systems help
Feature flags touch production behavior.
Mistakes are risky.
Structured systems like Avery.dev help:
define rollout logic clearly
enforce safe patterns
review changes before deployment
This prevents silent failures.
