Feature Toggle Bundle Laravel Package

Product Decisions This Supports

• Decoupling deploy from release. Feature toggles let engineering ship code dark and turn it on per environment, which is what makes "ship weekly / release on business timing" roadmap commitments credible.
• Progressive rollout and beta programs. Supports gating new flows (onboarding revamp, pricing page variants, new checkout) so a PM can sequence exposure by environment or cohort instead of a hard launch date.
• Kill switches for risk management. Gives a PM a non-rollback lever to disable a failing feature during an incident — a direct input into launch readiness checklists and incident response plans.
• Scoping decisions in the backlog. Because toggles are cheap to add, "should we build this behind a flag?" becomes a default yes for anything customer-facing and uncertain; this affects sprint sizing and QA plans (flag-on/flag-off test matrices).
• Build vs buy. This is free OSS with low integration cost, appropriate when flag needs are "on/off by environment" rather than targeting, experimentation, or analytics. It is the cheap option in the build-vs-buy comparison against LaunchDarkly, Unleash, Flagsmith, or GrowthBook — with the trade-off that targeting rules, audit logs, and a management UI are not included.
• Flag-debt governance. Every toggle introduces a cleanup ticket. A PM decision this enables: reserving capacity each quarter for flag retirement, and setting a policy (e.g. flags must have an owner and an expiry date) rather than letting toggles accumulate silently.

v6.0.0 impact on planning: this is a major version with breaking changes — the myclabs/php-enum dependency was removed and classes were re-typed. Any team relying on the previous enum-based toggle definitions or extending the bundle's classes will need code changes. Treat as a scheduled maintenance item needing engineering capacity, not a drop-in patch.

When to Consider This Package

Consider it when:

• The product needs simple on/off or environment-scoped toggles inside a PHP application, and the team already owns that codebase.
• You want zero vendor cost and no procurement cycle for flagging — useful for early-stage products, internal tools, or pre-launch betas.
• Flags are configured in code/config and changed by engineers as part of a release, which matches your operating model.
• You are standardising a small number of long-lived toggles and can accept the framework-coupled approach.

Look elsewhere when:

• Non-engineers (PM, marketing, support) need to flip flags themselves via a UI — this package does not provide a management console.
• You need percentage rollouts, user/segment targeting, or sticky bucketing for experiments; that is experimentation-platform territory.
• You need an audit trail of who changed what flag when — required in regulated or enterprise contexts.
• You run a polyglot stack and want one flag system across PHP, JS, mobile, and services.
• You need SLA-backed support; OSS maintenance here is small-team/volunteer-scale.
• Your upgrade budget is tight in the current cycle: adopting now means also absorbing a v6 breaking migration path.

How to Pitch It (Stakeholders)

For executives: This is a free, open-source feature-flag library for our PHP stack. It lets us ship code continuously while controlling when customers actually see a feature — reducing launch risk and giving us a fast off-switch if something goes wrong. Cost is engineering time, not licence fees. The trade-off: it is plumbing, not a product — no dashboard for business users, no experiment analytics, no vendor support. Adopt it if we want cheap release control; buy a commercial platform if we want marketing and product to run targeted rollouts and experiments without engineering.

For engineering: v6.0.0 is a major release — myclabs/php-enum was removed and classes are now typed — so it is a breaking change for any code using the old enum API or subclassing internals. Recommended path: pin a version, review the changelog diff for your usages, and schedule the upgrade as a discrete ticket rather than bundling it into feature work. For adoption, the pitch is straightforward: small surface area, no external service, flags live next to the code they gate. Set the expectation up front that toggles are temporary — require an owner and a removal date at creation, and budget cleanup time each quarter so we do not trade launch risk for permanent configuration debt.