Laravel Feature Flags Laravel Package

Product Decisions This Supports

Feature-flag infrastructure underpins a specific class of product decisions, and this package is a candidate to power them:

• Progressive delivery / staged rollouts. Ship a feature behind a flag, enable for internal users → beta cohort → percentage of traffic → GA. This lets PMs decouple release timing from marketing/GTM readiness and from support team staffing.
• Kill switches for risky surfaces. Checkout, payments, AI-generated content, third-party integrations — a flag lets you disable a degraded path without a redeploy, which changes the risk calculus on shipping ambitious changes at all.
• Plan- and entitlement-based gating. Turning features on per subscription tier or per account maps directly to packaging/pricing experiments without shipping separate builds.
• Dark launches and A/B-style experiments. Measure before announcing; ship the code path early, expose it deliberately.
• Customer-specific commitments. Sales-led "we'll turn that on for you next Tuesday" promises become an operational toggle rather than an engineering ticket.

The build vs. buy call this informs: build it ourselves (a DB table + a model + a helper) vs. adopt a package. A DB-backed Laravel package is squarely in "cheap to adopt, cheap to rip out" territory, so the PM-level decision is less about licensing cost and more about maintenance risk and API stability. That is precisely the axis on which v1.6.1 is informative — see below.

Assessment of v1.6.1 specifically: a single fix to the FeatureFlag facade alias, which previously pointed at a nonexistent plural class. No new features, no breaking changes, no deprecations. From a roadmap standpoint this is a no-decision release — it does not unlock capability, it does not force migration. It is, however, a credibility signal worth logging: the package shipped a documented facade that didn't actually resolve, which means the public API surface is still being tightened at the 1.x line, and you should not assume the documented usage is battle-tested.

When to Consider This Package

Adopt it when:

• You're on a modern Laravel version and want flags backed by your existing database rather than a per-seat SaaS contract.
• Your flag needs are structural (on/off, per-user, per-plan) rather than experimental (statistical significance, multi-variate assignment, exposure logging). This is not an experimentation platform.
• You value a small dependency you can read end-to-end in an afternoon and fork if the maintainer walks away.
• You want flags to travel with the codebase and your existing migration/deploy pipeline, with no new vendor in the security review.
• You're running a small-to-mid team where a single maintainer dependency is acceptable because you've accepted you may own the fork.

Look elsewhere when:

• You need experiment analytics, holdouts, or assignment auditing — go to LaunchDarkly, GrowthBook, or Statsig.
• You need flag targeting evaluated at the edge / CDN layer, or on non-Laravel services in your stack. A per-framework package fragments your flag source of truth across a polyglot estate.
• You require SOC 2 / vendor SLAs / named support. Single-maintainer OSS does not provide these, and the v1.6.1 facade bug is a concrete illustration of why that matters for regulated environments.
• Your flag count will grow into the hundreds with complex interdependencies — you'll want a managed service with a UI, audit trail, and stale-flag cleanup.
• You need a stable, frozen public API you can build documentation and onboarding around today. At 1.x with a recent facade correction, expect further small papercuts; budget a spike before you write internal docs against it.

Concrete pre-adoption check for this release: in a throwaway branch, install v1.6.1, register the facade, and confirm FeatureFlag:: resolves. The bug being fixed here is exactly the kind of thing that silently breaks a "quick" integration the day someone copies a snippet from the README.

How to Pitch It (Stakeholders)

To executives (30 seconds): We can add feature-flagging for near-zero cost by adopting a small open-source Laravel package that stores flags in our own database — no new vendor contract, no per-seat fees, no data leaving our infrastructure. It lets us ship features dark, roll out gradually, and turn things off instantly if something breaks. The trade-off is that it's maintained by a single developer, so we should treat it as "we may end up owning this code." Given it's a few hundred lines, that's a bet I'm comfortable making for internal tooling and non-regulated surfaces, and not one I'd make for regulated or revenue-critical paths without a fallback.

To engineering: Low-ceremony, DB-backed, native to our stack, forkable. The v1.6.1 release is a one-line facade alias fix — no action required if we're not yet on it, and a trivial patch bump if we are. The substantive read is that the documented facade didn't resolve until now, so treat the public API as "mostly stable" rather than "stable": pin the version, write our own usage notes rather than linking to their docs, and wrap flag reads behind a thin internal interface so swapping to a managed service later is a contained change. Please estimate that wrapper as part of the spike — it's our insurance policy against the maintainer going quiet.

To the wider business (support, sales, marketing): Nothing to communicate. This is infrastructure plumbing with no user-visible change.