Delia Laravel Package

Product Decisions This Supports

• Whether admin-panel findability is worth investing in at all. Delia is a bookmark/favorites layer for Filament resources — back-office users pin the resources they actually use instead of hunting through the nav tree. Frame it as a UX spend, not a platform bet: is navigation friction in a resource-dense panel a voiced complaint? Under a dozen resources, the answer is no. Past twenty, this is a cheap experiment that yields a real signal either way.
• Build vs. buy on a contained feature. Bookmarking is narrow: a per-user pivot table, a toggle, a filtered nav render. A competent Filament team ships that in one to two days. Delia is the buy option; ~200 lines of internal code is the build option that removes upgrade coupling entirely. The decision isn't "can we build it" but "is adopting, tracking, pinning, and upgrading a single-maintainer dependency cheaper than owning code we control?" Price the internal build first — buying only wins if integration is genuinely below build cost.
• Roadmap sequencing against the Filament major. Release 3.0.0 exists solely to "support Filament 5." That makes adoption a rider on the platform-upgrade decision, not an independent vendor pick. Delia enters the roadmap only inside the 4 → 5 migration, on the same branch; panels staying on Filament 4 stay pinned to ^2.0. Any plan treating Delia as a standalone feature is mis-sequenced and will stall in dependency resolution.
• Setting dependency posture as an explicit standard. 7 stars, 0 dependents, MIT, a one-line release note, and docs that describe a menu manager rather than a bookmark manager. This is an evaluate-and-trial candidate — never a standardize-across-the-estate candidate. The PM call is to state, in writing, whether single-maintainer / zero-adopter packages are permitted on internal panels and under what conditions (flag-gated, named internal fork owner, documented rollback).
• De-risking a larger UX investment. Bookmarks are a cheap validation step before personalized navigation, saved dashboards, or admin search. If trial users don't pin resources, you've learned that before funding the bigger build.
• Blast-radius scoping. Internal, authenticated, low-consequence admin surfaces only. Not customer-facing, not revenue-critical.

When to Consider This Package

Consider it when:

• You are greenfield on Filament 5 or already committed to that upgrade, and nav friction in the admin panel is a real complaint, not a hypothetical.
• You want a fast, cheap UX experiment (favorites/bookmarks) to test demand before investing in custom navigation or personalized dashboards.
• The team accepts low-adoption MIT dependencies and will (a) audit the small source, (b) pin versions and commit the lockfile, and (c) keep a fork-or-reimplement fallback ready.
• Users are internal only, and the plugin can be enabled per panel behind a config flag so removal is a one-line change.
• You can absorb the verification burden: multi-tenant scoping, cascade-delete behavior, authorization re-checks on bookmarked resources, and nav-render query counts (N+1 risk on large panels) are all yours to confirm — the vendor has no visibility into your tenancy or policy model.

Look elsewhere — or build it internals — when:

• You are on Filament 3/4 with no near-term 5 upgrade; you'd be adopting an old line with an unknown upgrade path.
• The panel is small enough that the problem doesn't exist, or Filament's native navigation pinning already covers the need.
• You operate multi-tenant panels and the published schema lacks a tenant discriminator — per-user bookmarks will leak across tenants, and that's not a risk worth a shortcut button.
• The surface is customer-facing or revenue-critical, where an unmaintained dependency or an untested UX regression carries real cost.
• Your org can't name an internal owner for the fork decision. Bus factor is one; plan for it.
• Documentation credibility matters to your review process — the package description doesn't match what the code does. That's a diligence flag, not automatically a blocker, but it means you read src/ and the migration rather than the README.

How to Pitch It (Stakeholders)

To executives (one paragraph): We have a small, contained navigation-friction problem in our internal admin panel: past a couple dozen resources, staff hunt for the handful of screens they use daily. Delia is a mature-licensed (MIT) bookmark plugin for Filament that lets users pin the resources they use — roughly a day or two of work to replicate, so it's a low-stakes experiment. I'm recommending a flag-gated pilot on one internal panel only, tied to our existing Filament 5 upgrade rather than run as a separate project. Success criteria: pilot users actually pin resources and support tickets about "where do I find X" drop. Cost of failure is one config flag and a rollback we've documented in advance.

To engineering: Treat this as an evaluate-and-trial dependency, not a standard. It ships as a Filament panel plugin; 3.0.0 is a hard cutover for Filament 5 and 2.x stays for 4 — dry-run the Composer resolution before touching the lockfile, because the likely failure mode is blocking our Filament upgrade, not anything Delia does. Register it per panel behind config('features.delia'), publish config and migrations, and customize through config keys rather than subclassing; the moment we fork the model or migration, we own a fork and should record that in the ADR. Before we enable it anywhere real, we verify four things ourselves: tenant scoping in the migration, cascadeOnDelete on user and resource foreign keys, whether bookmark lists respect canAccess() on targets, and query count on our largest panel. Add one Livewire assertion that a toggle persists a row — that's our tripwire for a silent break on the next bump.

To the pilot group / internal users: A "pinned resources" shortcut on top of the normal navigation — standard nav stays exactly as it is, this just saves you the repeat trip. Available on the admin panel; tell us which screens you'd pin.

What I need approved: (1) the pilot panel and its users, (2) a named internal owner for the dependency, (3) agreement that this rides the Filament 5 branch and does not become a separate workstream, and (4) acceptance that if the trial shows no pinning behavior, we stop — and revisit bookmarks only as part of a larger personalized-navigation decision.