Filament Feature Flags Laravel Package

Product Decisions This Supports

• Decoupling release from deploy. The core PM value of feature flags is shipping code dark and turning it on per environment, cohort, or tenant. This package gives non-engineers a UI to flip that switch, which turns "can we get this in this sprint?" into "when do we want to enable it?" — a scheduling decision rather than an engineering one.
• Kill-switch policy for risky roadmap items. Anything with a rollback cost (payments, migrations, third-party integrations, AI features with cost-per-call) should ship behind a flag. This package makes the flag operable by on-call/support without a deploy, which is the difference between a 2-minute mitigation and a hotfix cycle. That directly changes your risk appetite on the roadmap.
• Beta / early-access programs. Gating features to a cohort (design partners, internal users, a specific plan tier) is a product decision, not an infra one. The admin UI lets you run a beta without a separate branch, release train, or customer-specific build.
• Packaging and monetization gating. Flags keyed to plan/tenant are the lightweight version of entitlement management. Useful for launch sequencing (feature exists, sold separately, enabled per account) and for soft-launching paid tiers. Note: this is a toggle, not a billing/entitlement system — don't let it grow into one.
• Build vs. buy for internal admin tooling. The realistic alternative is a hand-rolled CRUD screen in your admin panel. This package is a thin, opinionated wrapper on top of your existing flag storage, so the decision is really "spend a day building our own or adopt a small dependency." For a team already on Filament, adoption is close to free; the buy case is the maintenance you don't write.
• Experimentation readiness (limited). It supports the plumbing for A/B tests, but not the experimentation discipline — no statistical engine, no assignment consistency guarantees at scale, no cross-service SDKs. Treat it as an enabler for simple on/off and cohort experiments, not a replacement for an experimentation platform.

When to Consider This Package

Adopt when all of these are true:

• You are already on Filament for internal admin. This is the hard prerequisite — the entire value is the panel UI. Without Filament, the package adds nothing you can't get from your flag backend's own dashboard.
• You already have (or are standardizing on) a Laravel flag backend — Laravel Pennant, a features table, config-based flags — and you need a human-friendly control surface on top of it.
• Your audience for toggling is internal: PMs, QA, support, solutions engineers. The win is removing engineering from the loop for routine on/off decisions.
• Your flag model is simple: on/off, per-environment, per-user or per-tenant. You do not need percentage rollouts with bucketing, multi-variate flags, or targeting rules.
• You want a small, auditable dependency rather than a vendor contract. Low lock-in, readable source, easy to fork.

Look elsewhere when:

• You're not on Filament. Building a Filament panel to use a Filament package is backwards.
• You need real targeting and segmentation — percentage rollouts, attribute-based rules, mutual exclusion, holdouts. That's LaunchDarkly, Unleash, Flagsmith, or GrowthBook territory.
• You need governance. No evidence here of audit logs, approval workflows, change history, or RBAC granularity. If flags control production behavior in a regulated environment, "who flipped this and when" is a compliance requirement, not a nice-to-have.
• You're polyglot or multi-service. This is a PHP/Laravel admin surface. Flag evaluation in a Go service, a mobile app, or edge middleware isn't in scope.
• You need vendor-grade maturity signals. This is a single-maintainer package with no dependents recorded. That's not disqualifying — it's a maintenance-risk input, not a capability input — but it should push you toward pinning versions and wrapping the package behind your own thin abstraction so it's replaceable.

Adoption guardrail: wrap it. Don't let controllers and Blade templates call the package's facade directly; call your own Feature::enabled() seam. That keeps the exit cost near zero if the package stalls or your needs outgrow it.

How to Pitch It (Stakeholders)

To executives — the business case in one line: it lets us ship features continuously while deciding separately when each one goes live, which shortens time-to-market and lowers the cost of a bad release.

• Faster iteration, bounded risk. We deploy code that's off; turning it on is a decision, not a deploy. A problem becomes a toggle, not an incident.
• Cheaper betas and launches. Running a design-partner beta or a staged rollout stops requiring a branch or a special build — so we say yes to more of them.
• Less engineering time on non-engineering requests. "Can you turn X on for account Y" currently costs an engineer a context switch. It becomes a two-minute admin action.
• Small, reversible commitment. It's a thin layer over our existing Laravel flag storage, not a platform. If it doesn't work out, we remove it without rewriting application logic — provided we keep the integration behind our own interface.

To engineering — the honest framing:

• It's a thin Filament resource over your flag store. No new runtime, no new service, no new failure domain in the request path that isn't already there.
• Value is entirely contingent on being a Filament shop. If we're not, decline — this is not a reason to adopt Filament.
• Maturity risk is real but manageable: single maintainer, no recorded dependents. Mitigations are version pinning and a one-file abstraction seam. Don't let its API leak into domain code.
• It does not solve flag evaluation, caching, targeting logic, or audit. Those stay our problem (or Pennant's).

To support/ops — what changes for them: they get a self-serve toggle panel with no deploy and no engineer in the loop, which shortens mitigation time on flagged features. What they don't get is a change log — until that gap is closed, coordinate on a manual convention (ticket or channel note per toggle) before handing over production access.