Laravel Feature Laravel Package

Product Decisions This Supports

• Decoupling deploy from release. Flags let engineering ship code to production continuously while product controls when a capability becomes visible. This directly shortens the "code complete → customer-visible" lead time and removes release-night coordination from the roadmap.
• Progressive and staged rollouts. Enabling a feature for internal users, then a design-partner cohort, then general availability is a risk-management decision, not just an engineering one. It lets product expand blast radius on evidence rather than on a launch date.
• Kill switches for risky dependencies. When a new integration, pricing rule, or third-party API misbehaves, a flag lets the team disable the surface without a hotfix or rollback — a measurable reduction in incident duration and revenue exposure.
• Beta / early-access and entitlement gating. Per-user and per-environment toggles support invite-only programs, customer-specific feature access, and B2B tier differentiation without branching the codebase or maintaining parallel releases.
• Per-environment configuration. Staging-on / production-off is the default posture that makes demos, QA, and sales sandboxes cheap to run.
• Roadmap input on build vs. buy. Adopting a lightweight OSS flag layer now is a deliberate deferral of the "do we need a feature-management platform?" decision. It buys real signal — how many flags we actually run, whether we need targeting rules or experiment analysis — before committing budget to a vendor or to an in-house system.
• Best-fit use cases: internal tools, MVPs, and small-to-mid SaaS products with a modest flag inventory (roughly under a few dozen toggles) where flags are binary or user-scoped rather than rule-driven.

When to Consider This Package

Consider it when:

• The application is on an older Laravel line (roughly 5.x–6.x era) where this package's service provider, Blade directive, and middleware ergonomics still apply.
• The flag model is genuinely simple: on/off, per-environment, and per-user or per-model checks. No percentage bucketing, no attribute-based targeting, no experiment statistics.
• You want DB- or config-backed toggles with zero SaaS spend and no vendor procurement cycle, and you're comfortable owning the code.
• The team is small enough that flag governance can be a convention (naming, cleanup cadence) rather than a platform with RBAC and audit logs.
• You're willing to pin the dependency and accept that you may need to fork or vendor it.

Look elsewhere when:

• You're on Laravel 10+. Laravel Pennant is first-party, free, actively maintained, and covers scoped flags (per-user, per-team) with a clean API. For greenfield work this package is effectively superseded — adopting it would be buying maintenance risk for no capability gain.
• You need targeting rules, sticky percentage rollouts, or experimentation with exposure tracking and statistical readout. That's LaunchDarkly, GrowthBook, Unleash, or Flagsmith territory.
• You need governance: audit trails of who flipped what and when, RBAC on flag changes, approval workflows, or evidence for SOC 2 / compliance reviews.
• You need multi-service or multi-language flag evaluation, or flags that must be consistent across web, mobile, and backend workers.
• Maintenance signals are poor. At ~210 stars with a single maintainer, verify the last commit date, open-issue responsiveness, and Composer version constraints before adoption. Unmaintained flag infrastructure is a silent single point of failure on your release path — the exact system you rely on during an incident.
• Flags would gate security-sensitive behavior. Never let an unmaintained dependency sit in front of authorization or payment paths.

How to Pitch It (Stakeholders)

For executives (one paragraph): Feature flagging is a cheap, high-leverage release-safety capability: it lets us ship code continuously while product decides when customers see it, gives us instant kill switches when something misbehaves, and lets us run invite-only betas and tier-based entitlements without forking the product. This specific package is a zero-license-cost, MIT-licensed option that would take days, not weeks, to integrate. The caveat is maintenance: it's a small, single-maintainer project and appears aimed at older Laravel versions, so I'd treat it as a tactical experiment rather than a platform commitment. My recommendation is a time-boxed spike in a non-critical service to validate the workflow and measure how many flags we actually run — and if we're on Laravel 10 or later, we should use the framework's built-in Pennant instead at the same price. Either way, we should not commission an in-house flag system this quarter.

For engineering (the ask): Verify Laravel version compatibility and Composer constraints first; if it's stale, tell me immediately rather than patching around it. Assuming it's viable, integrate behind a thin internal interface (a FeatureFlags contract with active(string $flag, $scope = null)) so the underlying driver is swappable to Pennant or Unleash later without touching call sites. Please also give me two things alongside the integration: a flag-naming convention and a cleanup rule (every flag gets an owner and an expiry date). Flags that never get deleted become permanent branching in the codebase, and that cost lands on engineering, not on the launch.

Decision requested: approve a 1–2 day spike, with a go/no-go review against Pennant as the default alternative.