Product Decisions This Supports
- Feature scoping: ban vs. suspend vs. softer interventions. The package treats access denial as a first-class primitive with support for temporary suspension (expiry) and permanent bans. That forces a product conversation about which behaviors warrant which tier of enforcement — a requirement decision, not just a technical one.
- Build vs. buy for moderation plumbing. The underlying build is a nullable timestamp/boolean column, a middleware check, a login guard, and a Filament action. A competent team ships that in 1–3 days. The package buys that time; the price is a low-adoption dependency sitting in the authentication path.
- Roadmap input: is Trust & Safety a real workstream? Adopting this is a cheap way to validate whether moderation is an actual roadmap item (community, UGC, marketplace, free tier with abuse) or a hypothetical. If it's real, this package is a starting point, not an answer — real T&S needs reason codes, audit trails, appeals, and reviewer attribution.
- Enforcement consistency across surfaces. The stated value is one policy enforced at panel, API, and login. That's a genuine product position — decide explicitly whether mobile clients, webhooks, and third-party integrations are in scope, because middleware in a Laravel app won't reach them.
- Support-operations placement. Whether ban/unban actions live in Filament's admin panel or in a dedicated support tool. If your moderators or CS team don't already use the Filament panel, most of this package's value evaporates.
When to Consider This Package
Consider it when:
- You are already running Filament and your support/admin staff perform moderation directly in the panel — marginal cost is one
composer require and a trait.
- You need basic abuse enforcement quickly (a kill switch for hostile accounts) at a stage where a bespoke implementation competes with core product work.
- Enforcement surface is limited to panel + Laravel API + web login, matching the package's stated coverage.
- You can pin the version, wrap the trait and middleware in your own regression tests, and accept single-maintainer maintenance risk.
Look elsewhere when:
- You need audit- or compliance-grade moderation — who banned whom, when, why, appeals, retention obligations. Build it or evaluate a dedicated moderation service.
- You need multi-tenant or scoped bans (ban from one organization, not the platform), delegated moderation, or tiered roles.
- Auth-path risk is material. A 10-star package guarding login means a bug there is an outage or an incident; without a security review, you're trading days for tail risk.
- You require maintenance guarantees, SLAs, or vendor support.
- Non-Filament surfaces (mobile SDKs, websocket auth, gRPC) need enforcement this package doesn't cover.
How to Pitch It (Stakeholders)
Summary: A small MIT-licensed Filament plugin that adds ban/suspend enforcement across the admin panel, API, and login — worth roughly 1–3 dev days of moderation plumbing, at the cost of a dependency we must review and own.
For executives: This accelerates a moderation capability we may need soon at effectively zero licensing cost. The caveat is maturity: low adoption, one maintainer, and it operates in a security-sensitive path. Recommendation is a time-boxed spike, not a foundation dependency — adopt only if it clears security review and we wrap it behind our own interface so we can swap it out without a rewrite.
For engineering: Expect a trait, a migration, middleware registration, and Filament actions. Treat it as a thin reference implementation: vendor or fork it, own the tests, and keep a one-day exit path to a bespoke is_banned column plus middleware. Do not let its schema leak into domain logic or authorization policies.
Recommendation: Conditional pilot. Verify compatibility with our Filament version, write regression tests around login and API bypass, and time-box evaluation to one week. If it doesn't clear the bar, build the three-day version — the value here is convenience, not capability.