Sylius Feature Flag Bundle Plugin Laravel Package

Product Decisions This Supports

• Feature rollout and roadmap sequencing. Lets the team ship code dark and enable capabilities per environment (or per merchant/instance) without a redeploy, so roadmap items can be staged and validated before public commitment.
• Build vs. buy for flag management. The decision it most directly replaces is "do we build an internal admin CRUD for toggles?" This package supplies the Sylius resource, grid, and Doctrine provider for free (MIT), so the real comparison is this package vs. 1–3 days of internal glue code vs. a SaaS flag vendor.
• Ops/CS autonomy. Because flags live in the admin panel with code, enabled, value, and description, non-engineers (support, ops, merchandising) can flip a capability or adjust a value during an incident or launch window without a ticket to engineering — a meaningful reduction in time-to-mitigate.
• Kill-switch and incident response. A DB-backed provider registered at high priority means a persisted flag overrides a code-defined @AsFeature of the same code — i.e., the "off" switch survives deploys and is controllable at runtime.
• Experiment and pricing/promotion gating. The value field allows simple parameterized flags (e.g., threshold, variant label), supporting lightweight experiments and staged pricing or checkout changes.
• Scope is deliberately narrow. Flags are global: no percentage rollouts, user/segment targeting, channel scoping, or audit trail. Decisions requiring those capabilities must be made elsewhere; this package only answers "is this capability on, and with what value?"

When to Consider This Package

Consider it when all of the following hold:

• You are on Sylius 1.8/1.9 with Symfony 4.4 and PHP ≤ 8.1 — the package's declared support matrix. On PHP 8.2+/Symfony 6+/newer Sylius, assume incompatibility until proven otherwise and budget a fork-and-patch spike.
• You already use (or are willing to adopt) em411/feature-flag-bundle; this is a provider + admin UI add-on, not a standalone system. Adopting it means adopting that dependency chain too.
• You want operator-facing toggles, not experimentation infrastructure — global on/off plus an optional value is sufficient.
• Your flags are low-blast-radius and reversible: internal tools, secondary flows, cosmetic or promotional changes. Not payments, tax, or inventory correctness.
• You accept zero community validation (0 stars, 0 dependents) and a single-maintainer bus factor, and can absorb the cost of vendoring or forking.

Look elsewhere when:

• You need targeting, percentage rollouts, segment rules, or per-channel scoping — use LaunchDarkly, Unleash, Flagsmith, or a Symfony-native flag layer instead.
• You need audit logging, approvals, or RBAC on who changed which flag — a compliance requirement this package does not address.
• You need vendor support, SLA, or a security review trail; a 0-star, single-author package with a short release history won't clear procurement.
• You are on a modern Sylius/PHP stack — the maintenance burden of patching an abandoned constraint set will likely exceed writing ~200 lines of Doctrine + admin CRUD yourself.
• Flag evaluation is on a hot path — verify the provider does not add a query per check before committing; caching behavior is unspecified in the README.

How to Pitch It (Stakeholders)

For executives: A free, MIT-licensed add-on that turns feature toggles into a point-and-click admin screen inside Sylius, so we can launch features gradually and turn them off instantly without engineering deploys. It's a low-cost experiment that buys operational speed and reduces release risk. The trade-off is support risk: it's a small, unproven open-source component on an older Symfony/Sylius baseline, so I'd recommend a time-boxed spike, not a platform commitment.

For engineering: It's a thin Sylius plugin — registers a Doctrine-backed flag resource with an admin grid, and plugs a high-priority provider into the em411/feature-flag-bundle chain so DB flags shadow @AsFeature annotations. Install is two bundle registrations plus admin routing. Standard Symfony/Doctrine, nothing exotic. The concerns are the version ceiling (PHP 7.4–8.1, Symfony 4.4), no targeting or audit features, and a single-maintainer dependency.

Recommendation: Run a 1-sprint spike behind our own flag-interface abstraction so the provider can be swapped later; validate it on our actual Sylius/PHP versions before any production exposure, and restrict initial use to reversible, non-critical flags. Only promote to a platform standard if the maintainer activity and version support improve — otherwise fork it or build the ~1-day equivalent in-house.