Filament Pinnable Navigation Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-panel UX polish. Pinning is a small but high-signal power-user feature. This package lets you ship it in an afternoon instead of spending a sprint on custom Filament navigation hooks, local persistence, and collapse-mode edge cases. If your roadmap has "improve internal tool usability" as a theme, this is a cheap, low-risk way to demonstrate motion.
• Feature prioritization for internal tools and back-office panels. When you're deciding whether to invest in navigation customization vs. new workflows, this package de-risks the "nav ergonomics" bet because it's a plugin registration plus optional published config—not a fork. Use it to test the hypothesis that personalized navigation improves task completion time before committing engineering budget to a bespoke solution.
• Differentiating operator-facing products. If your product is sold to operations teams (support desks, logistics, finance ops) who live in the admin panel all day, pinnable nav is a visible quality-of-life feature you can put in release notes and sales demos. It's not a headline feature, but it compounds.
• Roadmap sequencing around Filament 5. The package is strictly Filament 5 / PHP 8.2+. That makes it a post-upgrade enabler: adopt it as a payoff for teams that have completed or are planning a Filament 5 migration, giving the upgrade a tangible user-facing benefit.
• Deciding on persistence strategy (product, not just technical): the database_enabled flag is a product decision. LocalStorage = zero migration, per-browser pins, fast; database = pins follow the user across devices, better for hybrid/field teams and shared workstations. Pick per persona: desk-bound admins vs. multi-device operators.
• Informing "do we need role/tenant-aware navigation?" The package does not natively scope by role or tenant. If your roadmap includes multi-tenancy or persona-based panels, this package surfaces the gap early, letting you decide whether to build scoping now or accept flat pinning per panel/user.
• Validating adoption with a feature flag. Because it's config-driven (group title, icons, accordion mode, resource-header toggle), you can pilot it on a single panel or internal environment and measure engagement (how many users pin items, which items get pinned most) before rolling out broadly.

When to Consider This Package

Adopt when all of the following are true:

• You are on Filament 5 (or upgrading imminently) and PHP 8.2+. This is a hard gate—there is no Filament 4 or earlier support.
• Your users navigate a large, grouped sidebar and routinely hop between the same few resources. The value proposition collapses if your panel has fewer than ~8 destinations.
• You want a fast, low-effort UX improvement and are comfortable with a single-maintainer, early-stage package (12 stars, 0 dependents, version 1.0.x). Review the code once; it's small and MIT-licensed.
• LocalStorage persistence is acceptable for your first version, or you're willing to run the published migration and flip database_enabled for cross-device pins.
• You can live without built-in role/tenant scoping—or you're willing to add it yourself (middleware or a forked persistence layer).
• You have a staging environment to validate sidebar behavior in collapsed mode, with custom themes, and alongside any other navigation plugins (release notes show ongoing fixes for clustered items leaking, collapsed-mode dropdowns, and pin-button positioning—good signs of maintenance, but also signals of a young surface area).

Look elsewhere or build in-house when:

• You are on Filament 3/4 or cannot move to 5—no path here.
• You need first-class multi-tenancy, per-role pin sets, or audited/analytics-tracked pinning. The package exposes no events or hooks for this; you'd be forking it.
• Your navigation is custom-built or non-Filament. The plugin hooks into Filament's panel/navigation system specifically.
• Vendor risk tolerance is low. A single maintainer, no dependents, and a recent initial release mean you should have a plan (fork, pin version, or accept removal cost—which is low: uninstall is just removing the plugin and optional table).
• You require long-term support guarantees or a formal SLA. The "Need something custom?" section confirms this is a small studio offering bespoke work, not an enterprise-supported product.

How to Pitch It (Stakeholders)

For executives (30-second version):

We can add personalized "pinned" shortcuts to the sidebar of our Filament admin panel with a small, MIT-licensed plugin—roughly a day of work, not a sprint. It's a cheap, reversible UX win for the operators who use the panel daily, and a visible perk we can point to after our Filament 5 upgrade. Risk is contained: if we don't like it, uninstalling is one line of config plus an optional table drop.

For engineering:

It's a Filament 5 panel plugin registered via ->plugin(PinnableNavigationPlugin::make()), with optional published config and migrations. Default persistence is per-user, per-panel localStorage (no DB, no migration); flip database_enabled for cross-device persistence. Config exposes group title/icon, pin/unpin icons, a page-header pin toggle on resource index pages, and an accordion-mode toggle. Caveats for the team: single maintainer, ~12 stars, no dependents—so pin the version, skim the source (it's small), and plan for no built-in multi-tenant or role scoping. Recent patch releases fixed real issues (clustered items leaking into main nav, collapsed-sidebar behavior, asset bundling), which tells us it's maintained but still stabilizing. Recommendation: pilot on one internal panel behind a config toggle, measure pin adoption over two weeks, then decide on broader rollout and whether DB persistence is worth the migration.

For product/design:

Pinning is a familiar pattern (Slack, VS Code, Notion)—low training cost. We choose the group label and icons to match our brand, and we decide whether pins are per-browser or per-account. Success metric to watch: share of daily-active panel users who pin at least one item, and whether pinned users return to those items more often. If engagement is flat, we remove it with no user-data cleanup beyond an optional table.