Toggle Bundle Laravel Package

Product Decisions This Supports

• Release strategy and rollout risk: feature toggles let a PM decouple deploy from release — ship dark, enable for internal users, then ramp 1% → 10% → 50% → 100%. This directly supports decisions like "can we ship this before the marketing launch?" and "who is exposed if this breaks?"
• Kill-switch and incident response policy: a toggle service gives PM and on-call a non-deploy lever to disable a failing feature. Useful for deciding which features are required to be flag-guarded (payments, pricing, onboarding, anything with regulatory exposure).
• Experimentation and validation: coarse A/B or holdout cohorts for pricing pages, onboarding flows, and messaging — enough for directional product decisions, not for statistically rigorous growth programs.
• Entitlement and plan gating: flags per customer/segment for beta programs, design-partner access, and tiered feature availability without forking the codebase.
• Build vs. buy vs. adopt: the core PM decision here — do we build flags in-house, adopt an OSS bundle, or pay for a hosted service? This package represents the "adopt a small OSS library" option and should be evaluated against that baseline, not in isolation.
• Roadmap sequencing: because toggles lower the cost of unfinished work in production, they enable trunk-based development and smaller, more frequent releases — a prerequisite if the roadmap assumes weekly shipping.
• Use cases this fits: Symfony monoliths needing a lightweight, self-hosted flag layer with no vendor contract; internal tools where audit trails and approval workflows are not required.

Caveat on fit: the request frames this as a Laravel/PHP package, but qandidate/toggle-bundle is a Symfony bundle. It provides DI services and configuration wired into the Symfony container; it will not drop into a Laravel application without meaningful custom integration. If the codebase is Laravel, this package is effectively out of scope and the comparable first-party option is Laravel Pennant.

When to Consider This Package

Consider it when all of the following hold:

• The application is Symfony (not Laravel), and the team wants flags wired through the existing DI/configuration layer rather than a standalone SDK.
• Requirements are modest: conditional on/off evaluation by user, segment, or percentage, evaluated server-side, with configuration living in your own infrastructure.
• Data residency or procurement constraints rule out a SaaS vendor, and the team accepts operating the flag store themselves.
• The flag surface is small and stable (tens of flags, not hundreds with lifecycle governance), so a minimal library beats a platform.
• You have PHP engineering capacity to read and, if needed, patch the library — and to own the upgrade path.

Look elsewhere when:

• The stack is Laravel — use Laravel Pennant; it is first-party, actively maintained, and integrates with the framework's conventions out of the box.
• Adoption signals matter to you. This package has ~89 GitHub stars and zero known dependents, which is a thin evidence base for production-critical infrastructure. Low adoption means fewer eyes on edge cases, slower security response, and a smaller hiring/troubleshooting pool.
• You need governance features: approval workflows, scheduled rollouts, flag lifecycle/cleanup enforcement, audit logs, RBAC, or per-flag ownership. These are where commercial and mature OSS platforms (LaunchDarkly, Unleash, Flagsmith, GrowthBook) earn their cost.
• You need rigorous experimentation: stable bucketing with mutual exclusion, sequential testing, metric attribution, and guardrail analysis. A simple toggle library will produce results you cannot defend.
• You want managed SDK performance: local evaluation with streaming updates, edge evaluation, or sub-millisecond flag checks at scale.
• You require vendor-backed SLAs, support contracts, or SOC 2 evidence for procurement.

Before any adoption decision, verify: current maintenance cadence and commit recency, PHP/Symfony version compatibility with your runtime, whether qandidate/toggle (the underlying library, a separate repo) is healthy, test coverage, the config/storage backend options, and whether a maintained fork exists. A recent tagged release is necessary but not sufficient — check commit activity, open-issue responsiveness, and whether releases are substantive.

How to Pitch It (Stakeholders)

For executives — the decision in one paragraph: Feature flags are a risk-management capability, not a feature. They let us separate "code is deployed" from "customers can see it," which shrinks blast radius, shortens incident recovery from a rollback-and-redeploy to a config change, and lets us test pricing and onboarding changes on a small cohort before committing. The strategic question is not whether we need flags — we do — but whether we buy a platform, adopt a small open-source library, or build our own. This specific package is a minimalist, self-hosted option. It is cheap and keeps data in-house, but it is a Symfony bundle with very low community adoption and no commercial support, so it is a fit only for a Symfony codebase with modest, stable flag needs and in-house PHP capacity to own it.

Recommendation: Do not standardize on this package by default. Run a two-week spike comparing it against (a) the framework-native option — Laravel Pennant if we are on Laravel, or Symfony's own flag approaches if we are on Symfony — and (b) one mature platform (Unleash for self-hosted, or a SaaS vendor if budget allows). The evaluation criteria should be: stack fit, maintenance health, governance features we will need in 12 months, operational burden, and total cost including engineering time. My expectation is that the framework-native or mature-platform route wins, and this package serves as a useful reference point for what "minimal" looks like.

For engineering — what we would be signing up for: It is an MIT-licensed Symfony bundle wrapping qandidate/toggle; it contributes DI services and configuration so flags are injectable rather than hand-rolled. The integration work is small; the ongoing work is not. We own the flag store, the evaluation path on every request, the upgrade treadmill, and the cleanup discipline. Two risks to flag explicitly: the dependency chain (qandidate/toggle itself) needs a health check before we commit, and low adoption means we are largely on our own for edge cases and security patches. If we proceed, contain it behind our own thin abstraction so swapping the backend later is a configuration change, not a refactor — and set a flag-expiry policy from day one, because stale flags are how this capability turns into technical debt.