Rain Laravel Package

Product Decisions This Supports

• Dynamic dashboards and widget personalization — build vs. buy. This is a Filament plugin for composing dashboards out of configurable widgets, scoped per panel, per role, or per landing page. If "configurable summary views for different roles" or "let admins arrange their own dashboard" is on the roadmap, this is a legitimate buy candidate. The in-house alternative is a widget registry, layout persistence, per-role visibility rules, and default/reset actions — deceptively expensive plumbing (schema design, permissions, responsive layout edge cases) that produces no product differentiation.
• Landing-page composition without buying a CMS. The framing ("manage widgets for your Filament dashboard and your website landing page") suggests one widget model serving both back-office dashboards and public page sections. If real, that lets us extend the existing admin into lightweight marketing-page authoring instead of standing up WordPress/Strapi/Sanity beside it. Validate the public rendering path separately — the plugin may solve authoring only, leaving caching, SEO, and editorial workflow to us.
• Filament 5 upgrade sequencing. Release 5.0.0 exists solely to add Filament 5 support, which almost certainly drops Filament 3/4. That makes this a scheduling input to the admin-panel platform upgrade, not a feature decision. If we're on Filament 3/4, adopting this means stacking two majors in one change — treat it as a Filament upgrade project with the package as a passenger.
• Admin tooling velocity for a small team. For conventional CRUD and dashboard surfaces, a plugin removes weeks of UI plumbing. That's the real argument for considering it despite thin adoption, and the reason to time-box an evaluation rather than dismiss it on star count.
• Roadmap option, not a commitment. At 16 stars and zero dependents, this is unproven in production anywhere. The correct posture is to prototype against one real screen, estimate the gap versus a 2–3 week build, then decide.
• Standing dependency-risk line item. Adoption chains our upgrade calendar to three moving parts (Laravel, Filament, this plugin) and to a solo maintainer. Record it as a recurring cost, not a one-off.

Evidence caveat that gates all of the above: the package name (lara-zeus/rain), the repository (lara-zeus/dynamic-dashboard), the marketplace description ("table builder"), and the bundled docs appear to describe different products. The only release artifact is one line: "add support for filament 5." Until someone confirms from the README and composer.json which product this actually is, every decision above is provisional. That 30-minute check is the highest-value diligence available and should precede any roadmap date.

When to Consider This Package

Consider it when:

• We are already on, or firmly committed to, Filament 5. This release targets it exclusively. If we're on Filament 3/4, resolve that upgrade first — a 16-star dependency must never drive an admin-panel platform migration.
• The need is conventional dashboard/widget composition — summary cards, charts, list widgets, role-scoped visibility — not a bespoke analytics surface with custom query orchestration.
• Building it ourselves is a real cost. If the alternative is 2–3 weeks of registry/persistence/render plumbing, buying wins. If the package turns out to be a thin registration wrapper we could inline in a few hundred lines, it doesn't.
• We can absorb the maintenance tax of a forced package major each time Filament ships one.
• We accept solo-maintainer risk on a high-privilege surface. Admin panels hold auth and data-mutation paths. Budget for reading the source, pinning versions, and potentially forking.
• A 1–2 day spike confirms fit: install on a scratch branch, register on one non-production panel, build one real dashboard, publish config/assets, inspect widget query patterns.

Look elsewhere or defer when:

• Filament is absent or peripheral — the analysis is over.
• Public landing-page delivery is the actual driver. A plugin is the wrong layer for caching, SEO, and editorial workflow; a headless CMS is the cheaper long-run answer.
• We need LTS, security backports, or a support contract. A 16-star, zero-dependent package cannot provide them. If the dashboard becomes business-critical, we are self-supporting by default — that has to be an explicit, accepted cost rather than a surprise at the next Filament release.
• The widget surface would carry sensitive data for non-admin roles and we cannot verify that the package respects Filament policies and panel access. Until authorization is proven in source, treat this as an internal-only, single-panel tool.
• The codebase turns out to be a table/form builder. That overlaps directly with Filament's own table system, which inverts the build-vs-buy math — inlining is then cheaper than tracking its majors. Confirm from source, not marketing copy.

How to Pitch It (Stakeholders)

For executives — one paragraph: We have an opportunity to buy, rather than build, the configurable-dashboard capability on our roadmap: a small MIT-licensed Filament plugin that provides widget composition, per-role layout persistence, and defaults/reset out of the box. The equivalent in-house build is roughly 2–3 weeks of undifferentiated plumbing. The trade-off is maturity — 16 GitHub stars, no known production dependents, a solo maintainer, and a release cadence chained to Filament's major versions. Recommendation: approve a 1–2 day spike against one real admin screen, not a roadmap commitment. Cost of the spike is trivial; cost of skipping it and building blind is weeks.

For engineering — the shape of the bet: Treat this as a reversible decision with a designed exit. Before any integration code, spend 30 minutes resolving the product-identity mismatch between the package name, the repo, the marketplace blurb, and the bundled docs — they do not agree, and the answer changes the build-vs-buy math. Then:

• Pin exactly (^5.0.x, not ^5.0), commit the lockfile, run CI against it. With zero dependents there is no crowd to discover a broken patch release for us.
• Wrap it behind an app-owned seam (DashboardWidgets::for(User)) so package class names never reach more than one file. That seam is the swap-or-fork point when the package lags a Filament release.
• Scope registration to a single panel from day one — the most common production bug in this category is a widget leaking onto a panel it was never meant for.
• Own the persistence schema (dashboard_layouts / widget_settings with user_id, panel, payload) rather than inheriting the package's, because that is the artifact we need to export if we migrate off.
• Gate widget registration ourselves. Do not assume a widget querying Invoice::all() is role-scoped. Treat layout JSON as untrusted input on a high-privilege surface.
• Cover the integration, not the package: two tests — dashboard route returns 200 for a permitted user, 403 for an unpermitted one. Those catch most breakage on every Filament bump.

The honest framing to put in the PR: this is a small, unproven, solo-maintained dependency on an admin panel — a high-privilege surface. We are betting that a time-boxed spike plus a documented fork path is cheaper than rebuilding widget plumbing. If the package stalls on a future Filament major, we self-maintain; write that sentence down now, because it is cheap today and expensive as a surprise later.