Filament Email Verification Alert Laravel Package

Product Decisions This Supports

• Access control policy for the admin panel: This package makes it cheap to decide whether unverified staff/admin users can reach the Filament panel and how they are nudged. It supports a "soft gate" UX (persistent alert + resend verification) rather than a hard block, which is usually the right default for internal tooling where locking people out mid-task costs more than it saves.
• Security & compliance posture: If a buyer's security questionnaire or SOC 2 / internal audit asks "are back-office accounts required to have verified email addresses?", this is a checkable control with a ~30-minute integration. That turns a compliance checkbox into a same-sprint deliverable rather than a backlog item.
• Build vs. buy, resolved toward "reuse the pattern": The feature is small enough (a Filament render hook + Laravel's MustVerifyEmail + a resend action) that a "build" decision is defensible. The honest PM framing is: this package is a reference implementation and a time-saver, not a strategic dependency. Budget the decision as "adopt now, replicate later if needed," not "commit to a vendor."
• Onboarding/activation funnel: For B2B products where the admin panel is customer-facing (tenant admins, workspace owners), unverified-email banners materially improve reachability and reduce support-ticket volume from password-reset and notification failures. Worth A/B-ing or at least instrumenting.
• Roadmap triage: This is a ~1-story-point item that closes an observable gap. Adopting it frees the roadmap to spend the same week on higher-leverage work, provided you accept the maintenance caveats below.

When to Consider This Package

Adopt (or copy) when:

• You are already on Filament (v3-era; verify version compatibility before committing) and Laravel's native email verification is in use.
• You need a lightweight prompt-and-resend experience, not a full custom verification workflow.
• Your team is comfortable reading ~200 lines of PHP and forking under MIT if the maintainer goes quiet.
• The blast radius of the package failing is cosmetic (a missing banner), not a security regression.

Look elsewhere or build in-house when:

• Low adoption is a real signal here. 7 stars, 0 dependents, single maintainer. Treat this as an unmaintained-but-useful snippet, not a dependency you put in composer.json without a fallback plan. Pin the version and note the fork path.
• You need verification enforcement tied to SSO/OIDC, SAML, or enterprise identity providers — email verification is often redundant or actively confusing in those flows.
• You need multi-tenant scoping, custom notification channels, or non-Filament surfaces (customer-facing web app, API) covered by the same logic.
• You require vendor support, a security review with an SLA, or a maintained release cadence. None of that exists here.
• Your compliance regime demands a hard gate (deny access until verified). Confirm the package supports blocking rather than only alerting; if not, you're writing the middleware anyway.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed plugin that closes a security and UX gap in our admin panel — unverified accounts get a clear prompt and a one-click resend instead of silently missing notifications. Integration is measured in hours, cost is zero, and the risk is contained: worst case we lose a banner, not access control. It supports a compliance talking point and removes an item from the backlog at negligible cost.

To engineering: It's a thin Filament layer over Laravel's built-in email verification — no new infrastructure, no custom auth. Caveats are real and should be stated plainly: small project, low adoption, one maintainer. Recommended handling is to vendor or fork it rather than track upstream, pin the version, and confirm Filament compatibility in a spike before estimating. If the spike exceeds a day, build the equivalent ourselves — it is not a large piece of work, and owning it removes the maintenance question entirely.