Profile Filament Plugin Laravel Package

Product Decisions This Supports

• Build vs. buy for account management. A profile/security surface (personal details, password change, MFA enrollment, active session revocation, pending email change) is high-risk, low-differentiation work. This package is a concrete "buy" option to benchmark against a custom build estimate — realistically 3–6 engineer-weeks with security review, plus ongoing maintenance.
• Roadmap sequencing for security features. Multi-factor authentication and session management show up repeatedly as procurement blockers in B2B deals and as baseline expectations in SOC 2 / ISO questionnaires. This package lets you ship that checkbox without displacing a quarter of core-product capacity.
• Scope negotiation on enterprise asks. When a prospect asks "do you support 2FA and device logout?", this is a low-cost way to answer yes now rather than committing a roadmap slot. Useful for closing deals in the current quarter while buying time to design a first-class auth story later.
• Panel-level adoption decisions. Because it registers as a Filament panel plugin, you can decide per-panel: enable full profile + security on customer-facing panels, hide session/MFA pages on internal admin panels where SSO already handles identity.
• Compliance and audit readiness triage. Session listing, password re-confirmation, and "sudo mode" re-authentication are exactly the controls auditors ask about. Adopting this converts a set of open questionnaire items into "shipped, configurable."
• Prioritization of auth UX debt. The publishable config and opinionated defaults act as a reference implementation — even if you don't adopt it, it's a credible spec for what your own profile page should contain.
• Vendor and dependency risk planning. With 0 dependents, 39 stars, and a single maintainer, this is a decision to consciously accept a bet on a small open-source project — which is itself a PM-level call about maintenance ownership (see below).

When to Consider This Package

Adopt when most of these are true:

• You already run Filament 3.2+ panels and the profile lives inside that panel, not a separate customer-facing SPA.
• You need MFA, password change, and session management sooner than you can build them safely, and you're comfortable with a pre-1.0 dependency.
• Your team can absorb a fork-and-own posture: MIT license, publishable migrations/config, so worst case you vendor it.
• You have a concrete mitigation owner — someone who will pin the version, run the test suite in CI, and review changelogs on upgrade (the 0.3.0 release removed methods and moved page namespaces, which is the exact upgrade risk to plan for).
• The audience is internal ops staff, B2B back-office users, or an admin panel where a slightly opinionated UI is acceptable.

Look elsewhere when:

• You're not on Filament, or your account settings live in a separate customer-facing app.
• Identity is fully delegated to an IdP (Okta, Entra, Auth0) — you'd be duplicating session and MFA surfaces that your IdP already owns and that auditors prefer you not fork.
• You need long-term support, SLAs, or a stable public API for extension; the pre-release warning explicitly allows breaking changes without a major bump.
• You need deeply custom flows — step-up auth tied to specific actions, per-tenant password policies, custom session storage — where overriding an opinionated plugin costs more than writing the pages.
• You're already invested in Filament Breezy or a comparable plugin; running two overlapping profile packages is a maintenance trap.
• Your security review requires a named maintainer with a support commitment or a codebase with material community scrutiny; 39 stars and 0 dependents won't clear that bar on its own.

How to Pitch It (Stakeholders)

To executives (one paragraph): Account security is a recurring sales blocker and an audit requirement, but it's not what customers pay us for. This plugin gives us a production-ready profile and security surface — multi-factor authentication, password management, active-session revocation, email change — inside our existing Filament admin panels, for roughly a day of integration instead of weeks of engineering. It's MIT-licensed, so we own the code if we ever need to. The tradeoff is that it's a small, pre-1.0 open-source project; we de-risk that by pinning the version and budgeting a small amount of ongoing ownership. Recommendation: adopt for internal and back-office panels now, and treat the customer-facing surface as a separate decision.

To engineering (the honest version): It's a well-structured, tested Filament plugin by a known package author, covering the exact boilerplate nobody wants to write — MFA enrollment, password updates with re-confirmation, session/device listing, pending email verification. Install is composer + publish migrations/config + one ->plugin() call. Two caveats: (1) it's pre-1.0 and has already shipped breaking namespace changes, so pin the minor version and read changelogs before upgrading; (2) it's opinionated — expect to publish and override config, page classes, and views rather than configure everything. We should fork or vendor it if we extend it heavily, and add an integration test that exercises MFA enrollment and session revocation so upgrades surface regressions immediately.

What I'd want before signing off: a spike that installs it in a throwaway panel, confirms it works against our user model and existing auth setup, and produces a written estimate of customization plus a named owner for upgrades.