Toggle Bundle Laravel Package

Product Decisions This Supports

• Feature gating by account/tenant. The package's stated purpose — checking whether a feature is enabled "for a given account" — is the primitive behind plan-tier entitlements, beta access lists, and per-customer contract overrides. A PM can ship a feature to design partners or enterprise accounts without a separate release train.
• Progressive rollout and kill switches. Toggle state per account lets you stage a launch (internal → design partners → 5% of accounts → GA) and roll back a misbehaving feature without a deploy. That directly reduces the cost of being wrong on a roadmap bet.
• Build vs. buy for flag infrastructure. The package is a thin, MIT-licensed abstraction rather than a full flag platform. It frames the decision as "do we need a management UI, audit trail, and targeting rules (buy/build a platform), or just a code-level per-account check (adopt something small)?" — a useful forcing function before committing to vendor spend.
• Packaging and pricing experiments. Because the check is account-scoped rather than user-scoped, it maps cleanly to billing entities — useful for testing whether a capability belongs in the Pro tier or should be an add-on.
• Deprecation decisions. Flags create a cheap way to retire a capability for new accounts while grandfathering existing ones, letting a PM sequence sunsetting against contractual commitments.
• Roadmap sequencing signal (negative). The v1.0.0 release adds no capability and no changelog substance — its entire release note is "Initial release." Combined with zero stars, zero dependents, and a codebase that predates that tag by years, the version number is a stamp, not a signal of renewed investment. Any roadmap item that depends on this package still inherits abandonment risk. Treat it as a reference implementation, not a foundation.

When to Consider This Package

Consider it only when all of the following hold:

• You are already in the Symfony/PHP ecosystem this bundle targets — note the naming (Bundle) and the Landingi origin; the "Laravel" framing in the listing does not match the package's actual shape, and adopting it in Laravel would mean writing a bridge.
• Your need is genuinely narrow: a boolean/account-keyed feature check backed by your own storage, with no requirement for a targeting UI, experiment statistics, audit logs, or SDKs for multiple languages.
• Your team is comfortable vendoring or forking the codebase, pinning it, and owning maintenance and security review yourselves. The v1.0.0 tag justifies pinning to 1.0.0 rather than a branch or dev-main, but it does not change who is on the hook for fixes — you are.
• You treat it as a starting reference for naming and interface conventions rather than as a dependency you expect upstream fixes from. A single "Initial release" tag is not a maintainer roadmap.

Look elsewhere when:

• You need self-service flag management for PM/ops, staged percentage rollouts, or approval workflows — use Unleash, LaunchDarkly, Flagsmith, or a hosted equivalent.
• You are on Laravel and want native patterns — Laravel Pennant is the first-party answer and requires no bridging.
• You need flags as durable, audited entitlements tied to billing — that is a product-data problem, not a library problem; buy or build against your entitlement service.
• You need long-term vendor support, security patching, or a maintainer to escalate to. Zero stars, zero dependents, and a v1.0.0 whose only release note is "Initial release" give no evidence of a support surface; there is nobody to escalate to.
• The feature is revenue-critical and a flag failure means a customer-facing outage; the blast radius of an effectively unmaintained dependency is too high.

How to Pitch It (Stakeholders)

For executives (one paragraph): We evaluated a small open-source PHP component that answers one question — "is this feature on for this account?" It is a legitimate pattern and the right mental model for gating launches and tiers per customer, but this specific package remains effectively dormant: it just received its first version tag, and the entire release note is "Initial release" — no features, no fixes, no stated support commitment, and no adopters. Recommendation unchanged: adopt the pattern, not the package. Budget a small internal effort — a handful of engineering days — to implement an account-scoped flag check on our own stack, or pay for a managed flag service if we want a UI and audit trail. Either path is cheaper than inheriting an unmaintained dependency in a revenue path.

For engineering (one paragraph): This is a Symfony bundle from Landingi providing per-account feature checks; MIT, tiny surface area, no active maintenance, no downstream users to validate it. The v1.0.0 tag adds nothing beyond a version number — treat it as a pinning target, not as a revival. Two options: (a) fork it as an internal reference and reimplement the interface on top of our existing config/cache layer, or (b) take it as a pinned 1.0.0 dependency if we accept full ownership and security review. I recommend (a) — it costs little more, removes the abandonment risk, and lets us define the account-resolution and default-off semantics ourselves. If we want rollout percentages, targeting rules, or an operator UI, this package does not provide them and we should scope that separately.