Filament Profile Laravel Package

Product Decisions This Supports

• Self-service vs. ticket-driven account admin. A profile page is a ticket-deflection feature: password changes, name/email updates, and avatar swaps move from "ping IT / ping the ops channel" to a user-driven flow. Framing the decision as cost-per-ticket against build effort is what turns this from a nice-to-have into a roadmap line item.
• Build vs. buy vs. already-have-it. The most important decision this package surfaces is the third option. Filament ships a native profile page (->profile() on the panel configuration) in current versions. If we are on a supported Filament release, the correct PM call is neither build nor buy — enable the built-in and spend the saved time elsewhere. This package is only a candidate for older Filament majors or heavily customized panel setups.
• Reference spec for our own account settings page. Even when we don't adopt it, a working implementation is a cheap way to settle scope questions: which fields are editable (display name, email, password, avatar), whether email changes require re-verification, whether password changes require the current password, and what the page deliberately does not do (roles, permissions, billing, notification preferences).
• Sequencing against auth work. If SSO/SCIM, MFA enrollment, or session management is on the roadmap, a local profile page is a partial solution that may be superseded. Decide whether profile is a standalone quick win or a slice of a larger "account & identity" epic — not both.
• Supply-chain and maintenance posture. Zero dependents and a minimal footprint is a signal, not a reassurance. Adopting an unmaintained single-purpose package for a security-adjacent surface (password and email handling) sets a precedent we'd have to unwind later. The PM-level decision is to standardize on framework-native capabilities where they exist.
• Distinguishing internal admins from end users. This solves profile editing for Filament panel operators. If the product need is "our customers manage their own accounts," this package is out of scope and should not anchor that conversation.

When to Consider This Package

Consider it when:

• The application is on a Filament version that predates the built-in profile page, and the team wants the capability in days rather than a sprint.
• The requirement is genuinely minimal — a single panel, a handful of fields, no tenant-specific variations — and the team is comfortable vendoring or forking the code rather than tracking it as a dependency.
• You want a concrete implementation to review with engineering and design as a reference before writing your own, particularly around avatar storage, validation rules, and the current-password confirmation pattern.
• The internal admin surface is low-risk (staff-only, small user count), so a small blast radius makes a lightweight dependency acceptable.

Look elsewhere when:

• Filament's native profile page is available. Enable it; do not add a dependency to duplicate framework behavior.
• Requirements include MFA enrollment, session/device management, audit trails of credential changes, SSO-linked accounts, or data export/deletion (GDPR/DSAR). A package this narrow will not carry those, and bolting them on costs more than building once.
• You need a maintained dependency with a security-response path. Confirm license, last commit, release history, and open-issue handling before any adoption — and treat "no activity" as disqualifying for anything touching credentials.
• Multiple panels, multi-tenancy, or per-role field visibility are in play; expect rigidity and plan to own a fork.
• The profile page is a stepping stone to a broader customer identity feature. Start there, not here.

How to Pitch It (Stakeholders)

For executives (30 seconds). This is a small open-source add-on that adds a "my profile" page — name, email, password, avatar — to the admin interface. The capability itself is worth having: it removes a recurring category of support requests and is table stakes for any internal tool. The important finding is that the framework we already use ships this natively, so the recommendation is to switch it on rather than adopt a third-party package. Estimated effort is on the order of a day of engineering plus review, with no license cost and no new vendor. The package is useful mainly as a reference for what the page should contain.

For engineering leads. Low effort, low risk, one dependency we should probably decline. If we're on a current Filament major, use the built-in profile page and spend the time on hardening instead: require the current password on change, invalidate other sessions, re-verify email on change, constrain avatar uploads (type, size, storage disk), and write an audit event for credential and email changes. If we're pinned to an older major, copy the package's approach into our own panel code rather than tracking it — the surface is small enough that ownership is cheaper than a fork. One day for the page, half a day for the hardening and tests.