Laravel Feature Flags Laravel Package

Product Decisions This Supports

• Decoupling deploy from release. Ship code dark, enable per environment or cohort. This is the core PM value: smaller batches, lower release risk, fewer rollback firefights, and a credible path to trunk-based development.
• Roadmap sequencing and staged launches. Gate unfinished work to internal users, design partners, or a beta list without maintaining long-lived branches. Lets you demo progress before committing to a public date.
• Progressive delivery. Ramp a change from internal → 1% → 10% → 100% to contain blast radius on migrations, pricing changes, checkout rewrites, or AI-driven features. The decision to expand exposure becomes an explicit, reversible business call rather than a deploy event.
• Kill switches on risky dependencies. A third-party integration, new payment provider, or experimental recommendation engine can be disabled in seconds without a hotfix or redeploy. This is an operational risk decision as much as an engineering one.
• Feature gating by plan, customer, or role — if the package's scoping model supports it. Confirm before you build pricing or entitlement logic on top of it; otherwise you will end up with two sources of truth.
• Build vs. buy for flag infrastructure. Replaces the common anti-pattern of config('features.x') plus environment variables sprinkled across the codebase. At small scale this is materially cheaper than a LaunchDarkly or Statsig contract, and flag state stays in your own database.
• Flag lifecycle and cleanup decisions. A central registry makes "which flags are dead, who owns them, when do we remove the branch" an answerable question — flag debt is a real maintenance cost that PMs should own a cadence for.
• Experimentation foundations — with a caveat. Assignment/exposure plumbing may be supported, but statistical analysis, guardrails, and metric pipelines are not. Treat A/B testing as a separate investment, not a free byproduct.

Verify before committing roadmap dependencies: scoping granularity (global / user / team / plan), percentage rollouts, caching and query behavior under load, behavior in queued jobs and console commands, and whether flags are evaluated per-request or per-process.

When to Consider This Package

Reasonable fit when:

• You run a Laravel monolith (or a small number of Laravel apps) with a team of roughly 3–30 engineers.
• You need flags that can be toggled without a deploy — i.e., database-backed state, not just config files.
• The required semantics are simple: on/off, optionally scoped to a user, team, or plan.
• You want zero vendor contract, zero external network dependency, and flag data to remain inside your existing database and backup/retention regime.
• You are willing to own the code: pin the version, read the source, and fork if the maintainer goes quiet.

Look elsewhere when:

• You need governance. Audit trails, approval workflows, RBAC, SSO, and flag-lifecycle enforcement are enterprise flag-platform features, not package features.
• You need experimentation. Significance testing, exposure logging, guardrail metrics, and warehouse integration belong to a dedicated platform or an in-house data build.
• You need multi-service or multi-language evaluation, edge/low-latency flag resolution, or streaming updates across a fleet.
• You need an SLA, SOC 2, or vendor support for a production-critical control plane.
• You are already on modern Laravel. Laravel Pennant is first-party, free, and covers much of the same ground. Run a comparison spike before adding a third-party dependency — defaulting to the framework's own tool is usually the lower-risk call.
• Maturity signals are thin. Single maintainer, low adoption, and no visible dependent projects is a real risk input. That does not disqualify it, but it means: no community safety net, slower fixes, and a higher chance you become the maintainer.

Adoption gate: run a two-day spike on one low-risk feature. Confirm Laravel version compatibility, test coverage, caching behavior, and whether the opinionated conventions match how you actually want to model flags. If the spike is clean, adopt behind your own thin abstraction so the vendor is swappable.

How to Pitch It (Stakeholders)

For executives — one paragraph: Feature flags let us separate "code is deployed" from "customers can see it," which is the cheapest available lever for reducing release risk and shortening time-to-market. This package is a small, Laravel-native, database-backed implementation: no per-seat SaaS contract, no external service in the request path, and flag data stays in infrastructure we already back up. The cost is low and mostly engineering time, not licensing. The risk is maturity — it is a small, single-maintainer project — so the recommendation is a contained pilot on one non-critical feature, with the integration isolated behind our own interface so we can swap to Laravel's first-party Pennant or a commercial platform without rework. Success criteria: one feature launched to a limited cohort without a redeploy, and a documented flag cleanup process.

For engineering — the ask:

• Evaluate this against Laravel Pennant first; if Pennant meets the need, prefer first-party.
• If adopting, wrap flag checks in our own service/facade rather than calling package helpers directly in Blade and controllers — this keeps the dependency surface small and the exit cheap.
• Define conventions up front: naming scheme, owner, expiry date, and default-off. Add flag removal to the definition of done.
• Watch the hot paths: confirm evaluation cost and caching before putting checks in high-traffic middleware or query scopes.
• Pin the version, and note in the ADR that we accept single-maintainer risk and may fork.

Decision requested: approve a timeboxed spike (1–2 days) plus a short written ADR selecting between this package, Pennant, and a commercial platform. This is a reversible, low-cost decision — but it should be made deliberately, because flag conventions calcify quickly and are expensive to retrofit.