Feature Flag Bundle Laravel Package

Product Decisions This Supports

• Feature-level kill switches for a Symfony codebase. If the team ships to a Symfony app, this bundle gives you a config-driven on/off gate per feature — enough to decouple deploy from release for a handful of risky surfaces (new checkout path, redesigned onboarding, a new pricing page).
• Build vs. buy on flag plumbing (small scale). With 0 dependents and a "very KISS" scope, this is a ~half-day of engineering you'd otherwise write yourself. The decision it informs is narrow: do we own 200 lines of config-driven flag code, or adopt someone else's? It does not settle the broader build-vs-buy question for a flagging platform.
• Roadmap sequencing of "dark launches." Teams can merge code behind a flag and decide later when to flip it — useful for deciding whether a feature ships this sprint or next without holding a branch.
• Scope boundaries as a product signal. The package's minimalism is itself a decision input: it tells you the team has not yet committed to progressive delivery (percentage rollouts, user targeting, experimentation). Adopting it is a vote for "simple gates now," which implicitly defers experimentation infrastructure.
• Not supported: A/B testing, cohort targeting, gradual percentage rollout, flag audit trails, or runtime toggling from an admin UI. Any roadmap item depending on those is out of scope for this package.

When to Consider This Package

Adopt when all of the following hold:

• You are on Symfony, not Laravel. The package is a Symfony bundle; despite the Laravel/PHP framing, there is no Laravel service provider, facade, or config integration. Laravel teams should look at Laravel Pennant (first-party, actively maintained) instead.
• Your flag needs are binary and low-volume. A dozen or fewer flags, toggled by config or environment, with no per-user targeting.
• The blast radius of a wrong flag is small. No compliance, billing, or entitlement logic gated behind it.
• You want zero operational overhead. No database table, no admin service, no vendor contract.

Look elsewhere when:

• You need targeting or experimentation. No user segmentation, percentage ramps, or metric attribution — use LaunchDarkly, Unleash, Flagsmith, or GrowthBook.
• You need a Laravel-native solution. Use Laravel Pennant or Laravel's Feature facade.
• Adoption risk matters. 25 stars and 0 dependents means effectively a single-maintainer package with no production track record to reference. For a flag system — which sits on the critical path of every request — that's a real continuity risk. Prefer vendoring or forking over a hard Composer dependency.
• You expect flag sprawl. KISS bundles typically lack lifecycle tooling (staleness detection, cleanup reporting), and flags that never get removed become permanent branches in your code.

How to Pitch It (Stakeholders)

For executives: This is a small, free, MIT-licensed utility that lets engineering turn features on and off without a redeploy. It is not a platform investment — it's a tactical convenience for a Symfony codebase, appropriate only if we've already decided we don't need experimentation or user-level targeting. It carries minimal cost and minimal strategic upside; treat it as a library choice, not a roadmap commitment.

For engineering: A deliberately minimal Symfony bundle for config-driven boolean flags — no database, no admin UI, no targeting rules. Roughly a day of work replaced. The tradeoffs: 25 stars, zero known dependents, single-maintainer risk, and no Laravel support. Recommendation: use it only in Symfony services with a small, low-risk flag surface, vendor or fork the code rather than depending on it directly, and pair it with a written flag-retirement policy so toggles don't accumulate as permanent debt. If the roadmap includes progressive rollout or A/B testing within the next two quarters, skip this and evaluate Unleash or Flagsmith now rather than migrating later.