Dynamic Dashboard Laravel Package

Product Decisions This Supports

• Build vs. buy for dashboard personalization. The package's entire job is per-user widget layout: registration, drag-and-drop arrangement, resizing, visibility, and persistence. That is a bounded, well-understood slice — the kind of thing we would otherwise estimate at roughly 2–4 engineer-weeks plus indefinite ownership of a drag-and-drop UI and a layout state model. The real decision is not "do we want a dashboard" (Filament already ships one) but "is personalization a differentiator we invest in, or table stakes we assemble." This package makes "assemble" a credible option with a known price.
• Rescoping admin/back-office roadmap items from screens to widgets. Any epic phrased as screens — ops dashboards, reporting views, internal monitoring, support consoles, customer admin surfaces — gets cheaper to schedule, because the container (page, layout, persistence, picker) is provided and only the widgets are ours. The right move is to re-point estimates on existing admin epics rather than spin this up as a standalone initiative.
• Widget catalog breadth in v1. Because widgets register config-style instead of being hand-placed per layout, the marginal cost of one more metric card is small. That shifts the v1 conversation from "which three widgets fit the schedule" to "ship a broad catalog and let users opt in" — usually the better launch posture and the harder one to justify without this capability in hand.
• Onboarding and activation experiments. Per-user layouts turn "default workspace" into a configuration surface rather than an engineering project. We can test new-account defaults (three widgets vs. eight), ordering, and role-based starting templates without a build per variant. This is the least obvious and most defensible reason to adopt: it buys experiment velocity, not just a UI.
• Filament upgrade sequencing. The only content of 5.0.0 is "add support for filament 5" — one line. That tells us the package's majors are welded to Filament's majors. Any admin commitment dated after our Filament 5 window must budget this bump in the same ticket with a single rollback point, and any commitment dated before the upgrade should not include this package at all.
• Vendor risk scoring in the selection matrix. 16 stars and zero dependents is the decisive pair of numbers. This is an early, thinly validated package inside a healthy ecosystem. Classify it explicitly as "viable with a fork fallback" at decision time so the question isn't re-litigated in every review.

When to Consider This Package

Adopt when all of these hold:

• We are already a Filament shop committing to Filament 5 this cycle. 5.0.0 is a compatibility bump for Filament 5 only; outside that boundary the package has no value, and adopting Filament in order to use it is backwards.
• Per-user dashboard personalization is on the roadmap and the credible alternative is building layout state, reorder UX, and persistence ourselves.
• Our widgets are relatively uniform — metric cards, charts, list summaries, tables — expressible through a registration pattern rather than bespoke interactive panels.
• The blast radius is admin-only, so an outage is visible to staff and absorbed by staff rather than to customers with revenue attached.
• We accept a single-maintainer, MIT-licensed dependency with effectively one line of documentation, and we are prepared to pin the version, read src/ as the real docs, and fork if the maintainer goes quiet.
• We can absorb a package major in the same cycle as a Filament major, including rebuilding theme assets and re-publishing views.

Look elsewhere when:

• We are not on Filament, or our admin surface is a thin custom Blade/Livewire app where pulling in Filament costs more than the feature saves.
• Dashboard layout is a core differentiator that needs behaviors this package won't cover: team or shared dashboards, layout versioning, per-role default templates, cross-device sync semantics, widget-level permissions. Those become extension points we own, and they may exceed what a fork can absorb.
• The surface is customer-facing and revenue-linked, and 16 stars / zero dependents is disqualifying under our dependency policy absent a committed fork-and-own plan.
• Compliance or audit requires first-party or vendored code; this widens supply-chain review for a non-differentiating feature.
• We need an SLA, a security disclosure path, and release-note discipline. A one-line changelog on a major version is the signal: assume we learn behavior by diffing source, and budget for it.
• We are mid-release on Filament 3 or 4. Do not adopt ahead of the upgrade. The package bump and the Filament bump land together or not at all.
• We already have a dynamic-dashboard approach. Pick one. Dual-running two layout models produces conflicting UX and duplicated widget code — a cost that lands on product, not engineering.

How to Pitch It (Stakeholders)

One line: a small MIT-licensed Filament add-on that gives every user their own reorderable, resizable dashboard — so we ship personalization as configuration rather than custom engineering, and it now tracks Filament 5.

To executives: the decision on the table is whether dashboard personalization is on the roadmap, and if so whether we buy or build it. Buying saves roughly 2–4 engineer-weeks of layout state, reordering, and persistence work on top of the admin UI we'd otherwise hand-roll, and it hands us an experiment surface for onboarding defaults. The trade-off is real but bounded: this is an early-stage, single-maintainer package with negligible adoption (16 stars, zero dependents) and one-line release notes, so we treat it as "adopt with a pin and a fork fallback," not a platform bet. There is no budget ask — the cost is a maintenance line item per Filament major plus a one-week timeboxed spike. Recommendation: approve the spike in a non-customer-facing admin panel, and keep it off revenue-linked surfaces until the spike and a widget-authorization design review clear.

To engineering: it's a Filament panel plugin — register it in the panel provider, publish config and migrations, and we own only the widgets. Blast radius stays admin-only by design; we don't reuse its layout logic outside Filament panels. Two constraints are non-negotiable: pin ^5.0 with a committed lockfile and never bump Filament and this package in separate deploys, and treat the widget list as an access-control surface — authorization lives in each widget (canView(), policies, scoped queries), because hiding a widget in the picker is not authorization. We'll funnel all widget registration through a single WidgetRegistry seam so a fork or replacement is a day of work, not a month, and keep the stock Filament dashboard behind a per-panel flag as a rollback path.