Feature Flag Bundle Laravel Package

Product Decisions This Supports

• Decoupling release from launch. Flags let you ship code dark and turn it on when the go-to-market motion is ready — relevant for coordinated launches, pricing changes, and partner-dependent features.
• Roadmap sequencing and risk management. Per-feature kill switches (backed by the read-only REST endpoint + kill switch) give you a cheap rollback lever that doesn't require a hotfix or redeploy, which changes how aggressively you can schedule a release.
• Build vs. buy for the flag primitive. This is a small, config-driven library rather than a flag platform. It answers "do we need to build flag plumbing?" with "no, for simple on/off gating" — while leaving the bigger platform question (targeting, experimentation, audit) open.
• Entitlement and tiering groundwork. Named managers map cleanly onto product surfaces or customer tiers (e.g. a manager per plan or module), which is useful when scoping packaging and bundle decisions.
• Use cases this fits: dark launches, internal/beta access, ops kill switches for risky integrations, per-route feature gating, and simple cohort gating where the cohort is known at config time.
• Use cases this does not fit: percentage rollouts, user-segment targeting, A/B or multivariate experiments, per-account overrides that must persist across processes, and any decision requiring an audit trail of who flipped what and when. None of that is in 0.1.
• Strategic note: the runtime overrides are per-process, so they are a debugging/ops convenience, not a control plane. Any decision that assumes "we can flip it globally in seconds" needs a different tool or a wrapper you own.

When to Consider This Package

Consider it when all of the following hold:

• Your stack is Symfony 7/8 on PHP 8.3+. This is a Symfony bundle, not a Laravel package — it will not drop into a Laravel app without an adapter, and adopting it in a Laravel codebase means owning that integration yourself.
• You need coarse on/off gating, not experimentation.
• Flag definitions can live in config and ship with the deploy — i.e. you are comfortable with flag changes being a deploy event rather than a runtime toggle.
• You want framework-native ergonomics (Twig, route defaults, #[RequireFeature] attributes) rather than an SDK call.
• You can absorb pre-1.0 API churn. At 0.1 there is no stability guarantee; treat it as a spike or an internal-only dependency until it reaches 1.0.

Look elsewhere if:

• You need progressive delivery (percentage ramps, sticky bucketing), targeting rules, or experiment analysis — evaluate LaunchDarkly, Unleash, Flagsmith, or Grower/ConfigCat style services instead.
• You need flags to be operable by non-engineers (PM, support, on-call) without a deploy — configurability-in-code is a hard blocker for that workflow.
• You are on Laravel and want a maintained, idiomatic integration — Pennant or a hosted SDK is the better comparison; this package would be a build-vs-buy decision you'd lose on integration cost.
• You need auditability, approval workflows, or multi-environment flag state — none of that exists here.
• You have a single team and fewer than ~5 flags — this may be more structure than the problem warrants; a config constant is cheaper.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source building block that lets engineering ship features turned off and switch them on later, and switch them off fast if something goes wrong. It reduces the cost and risk of a launch by separating "code is deployed" from "customers can see it." It is not a growth or experimentation platform — it won't run A/B tests or target specific customer segments — so it's a low-cost way to get the safety benefit of feature flags without buying a vendor product. Caveat worth stating plainly: it is a brand-new 0.1 release for Symfony, our stack is Laravel, and the integration work is ours to own. Recommendation is a time-boxed spike, not a platform commitment.

For engineering: Lightweight Symfony bundle, PHP 8.3+, Symfony 7/8. Config-defined flags with optional descriptions; a default manager plus named managers for grouping; checked from services, Twig, route defaults, or #[RequireFeature] attributes. Per-process runtime overrides for enable/disable/reset are useful in tests and local debugging. Optional read-only REST endpoint with a kill switch. Not included: percentage rollouts, targeting/segmentation, persistent runtime state, an admin UI, or any analytics. Note it is a Symfony bundle — a Laravel adoption requires a service provider bridge and a config loader, which is real but bounded work.

Ask: approve a 1–2 sprint spike to wrap the flag interface behind our own abstraction, validate it in one non-critical launch, and revisit at 1.0 or when we need targeting — at which point we re-run build-vs-buy against a hosted provider. Keeping the abstraction in front means the decision stays reversible.