Feature Flag Laravel Package

Product Decisions This Supports

• Progressive delivery and staged rollout: The package lets teams gate behavior behind feature flags at the framework level rather than burying conditionals in application code. That directly supports decisions about canary releases, beta programs, and percentage-based rollouts without shipping a new build for every cohort change.
• Route-level experimentation: v1.1.1's #[FeaturesFlagSwitchRoute] attribute means a PM can decide to expose an entire endpoint (e.g., a new checkout flow, a v2 API surface, an internal admin tool) only to flagged users. This turns "should we launch this feature to everyone?" into a configuration and toggle decision rather than a release-train decision.
• Kill-switch and blast-radius control: Class- and method-level blocking lets engineering wrap a risky integration or expensive code path so it can be disabled instantly in production. For a PM, that is a measurable reduction in rollback cost and incident duration — useful when justifying investment in release safety over pure velocity.
• Build vs. buy input: If the team is weighing a commercial flagging platform (LaunchDarkly, Unleashed, Flagsmith), this package covers the PHP/Laravel-side evaluation surface — attribute-driven gating, routing, and execution blocking — which is often the majority of what a Laravel product actually needs. That is a legitimate argument for building on an open-source package and spending the saved budget on analytics or experimentation tooling instead.
• Roadmap sequencing: Attribute-based gating encourages shipping dormant code behind flags, which supports a roadmap where features are merged continuously but revealed on a product calendar. It reduces the coupling between "code complete" and "announcement date."
• Use cases worth naming explicitly: dark launches, internal dogfooding, per-tenant or per-plan entitlement gating, A/B tests where the assignment lives in the app rather than in the client, and deprecation windows where old and new code paths coexist.

When to Consider This Package

Adopt or prototype when most of the following hold:

• The stack is Laravel/PHP and the team wants flags resolved in-process, with no network hop or vendor SDK on the request path. That matters for latency-sensitive endpoints and for teams that do not want a third-party dependency in the critical path.
• Flags map cleanly to code structure — controllers, routes, classes, methods. The attribute approach is a good fit when gating is coarse-grained and stable, not when you need hundreds of flags with complex targeting rules.
• You want flags to be visible at the call site. Attributes make gating declarative and reviewable in a diff, which is materially better for code review and for auditing what is gated than scattered if (flag('x')) checks.
• Engineering appetite for a small, single-purpose dependency is higher than appetite for operating a flagging service.
• You need a fast path to a kill switch for specific integrations without a full deploy.

Look elsewhere when:

• You need rich targeting — device, geography, account tier, custom segments, holdouts, mutual exclusion groups, or statistically rigorous experiment assignment. This package is a gating primitive, not an experimentation platform.
• You need a non-technical UI for marketing or ops to flip flags. Attribute-driven flags are developer-owned by construction; if the operating model requires PMs or support staff to toggle behavior, that is a mismatch and you should budget for an admin layer or a SaaS tool.
• You require audit trails, approval workflows, and change history as compliance evidence. Flag state living in config or a database needs its own governance story.
• You have non-PHP services that must read the same flags. A PHP-only resolution layer creates divergence the moment you add a Node or Go service.
• You need gradual percentage rollouts with sticky bucketing out of the box; verify this explicitly before committing.
• The codebase is heavy on dynamic dispatch or non-attribute patterns where class/method blocking would be brittle.

Two caveats to raise before adoption: attribute-based execution blocking deserves a review of how it interacts with dependency injection, queues, and console commands — a flag that silently prevents a job from running can be a data-integrity problem, not just a feature toggle. And the package's release history is short (this is a 1.1.x line), so treat the API surface as still settling and pin versions.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small open-source Laravel package that lets us turn features on and off in running production systems without redeploying. The practical effect is that we can launch to a small group first, expand gradually, and switch something off in seconds if it misbehaves — instead of the current pattern of full launches and full rollbacks. The new version extends that control to entire routes and to individual classes or methods, which means we can also disable a risky integration instantly. It is low-cost, removes a chunk of the case for a paid feature-flagging vendor, and its main limitation is that it is a developer tool: it does not give us an experimentation dashboard or a non-technical control panel. Recommendation is a contained pilot on one or two upcoming features to measure the reduction in rollback and hotfix effort before standardizing.

For engineering: The pitch is that flags become declarative and reviewable in the diff rather than imperative conditionals, and the 1.1.1 additions mean route registration and class/method execution are gateable at the framework layer. Ask for: a documented convention for flag naming and lifecycle, an owner and expiry date per flag, a plan for flag state storage and its failure mode (what happens if the flag source is unavailable — fail open or fail closed), and explicit test coverage for gated paths. The concern to voice is flag debt: without retirement discipline, the flag layer becomes permanent branching complexity.

For finance/procurement: The direct comparison is a per-seat SaaS flagging subscription. This package's licence cost is effectively zero, so the decision is really about engineering time versus subscription cost and about which capability gaps (targeting, UI, cross-language SDKs, audit) we are willing to live without. Frame the pilot as the evidence-gathering step that makes that trade-off defensible.