Filament Advanced Widgets Laravel Package

Product Decisions This Supports

• Admin & analytics feature scoping. When the roadmap calls for "a dashboard" (KPIs, trend charts, ops health, usage reporting), this package lets you decide how much of that surface is a configuration task versus a build task. It shifts the default from "we'll need a frontend ticket" to "PM defines the metrics, engineering wires the widget."
• Build vs. buy for internal reporting. Filament ships Stat/Chart/Table widgets; "advanced" widgets cover the gap for richer cards, visualizations, and layouts. The PM decision is whether that gap is worth 1–3 sprints of custom Blade/Livewire work or a pinned third-party dependency.
• Roadmap sequencing for back-office and client portals. If admin panels are a competitive differentiator (client-facing reporting, multi-tenant dashboards), this raises the ceiling on what a small team can ship per sprint. If admin panels are pure cost center, this shortens time-to-value without changing strategy.
• Timing the Filament upgrade. Version 4.0.0 of this package tracks Filament v4. That makes your Filament major upgrade a two-part decision, not one: platform upgrade plus plugin upgrade, ideally in the same cycle. Conversely, staying on Filament v3 means standardizing on this package's 3.x line and accepting that new features (RTL, v4 fixes) land only on 4.x. The PM question to force: "Is the Filament v4 migration on the roadmap this half, and does the dashboard go with it?"
• Localization and RTL markets. The stat widget now ships RTL support. If MENA/Hebrew/Arabic-speaking internal users or clients are on the roadmap, that's one fewer bespoke CSS ticket — but it's stat-widget-scoped, not a blanket i18n guarantee across the whole dashboard.
• Standardization on Filament as the admin layer. Adopting it is a soft signal that Filament is your admin platform of record — which affects hiring, contractor onboarding, and future plugin choices. A package release tied to Filament's own major version reinforces that coupling.
• Demo and design-partner velocity. Faster path to a credible, data-rich dashboard for sales demos and early customer feedback, before committing to a bespoke analytics build.
• What it does not decide. It is not a data/BI strategy, not a customer-facing analytics product, and not a reason to defer investment in your metrics layer. Widgets render numbers; they don't define them.

When to Consider This Package

Consider it when:

• You are on Filament — and now you should also confirm which line you're on. 4.0.0 targets Filament v4 and 3.x remains the path for Filament v3. Pin deliberately; do not let Composer resolve across the major boundary.
• Your dashboards are internal-facing or low-blast-radius (ops, support, finance ops, internal SaaS admin), where a cosmetic regression is an inconvenience, not an incident.
• You need widget types beyond Filament's built-ins and the alternative is hand-rolling them — the ROI case is strongest when it removes 2+ sprints of work.
• You have RTL or non-LTR locales in scope and want the stat widget to render correctly without a custom stylesheet.
• You want low lock-in: MIT license, small surface area, and a component model that maps to Filament's own — a fork or in-house replacement remains a realistic exit.
• Your team can absorb maintenance risk: still a small footprint (~95 stars, 0 dependent packages, low composite score) with limited third-party validation. The 4.0.0 release is a positive signal — the maintainer shipped v4 support promptly and merged two first-time contributor PRs — but responsiveness on one release is not yet a track record. Treat it as "evaluation-tier" that is trending up, not "platform-tier."
• Security/procurement review is lightweight. If you need a maintainer SLA, security contact, or long-term support commitment, this package will not clear that bar.

Look elsewhere when:

• Dashboards are customer-facing at scale — high data volume, strict latency, accessibility guarantees beyond widget-level RTL, or pixel-level brand requirements. Build directly on a charting library (ApexCharts, ECharts, Chart.js) or buy a BI embed.
• You are not on Filament, or are on a version outside a published major (v3 or v4). Mid-major or untested patch ranges are still a no.
• You need an actively supported vendor: a support contract, published deprecation policy, or a maintainer with a track record you can point auditors to.
• Your admin UI is a long-lived, high-traffic surface where an abandoned dependency becomes a migration project. In that case, vendor the code or write the widgets yourself.
• The widget set overlaps with what you already have — duplication is worse than a missing feature.
• You cannot schedule the Filament v4 upgrade. If you're staying on v3 indefinitely, adopt 3.x knowingly, and treat 4.x-only fixes and features as unavailable to you. Don't adopt 4.0.0 and assume v3 parity going forward.

Mitigations if you adopt: pin the exact major (^3 or ^4, never a range spanning both), wrap it behind a thin internal widget abstraction so it's swappable, add a visual regression check to CI, verify the config/method surface you depend on against the 4.x release (the labelColor/valueColor lookup bug fixed in 4.0.0 is a reminder that widget config APIs can shift), and record the fork/exit path in the ADR.

How to Pitch It (Stakeholders)

For executives: This is a small, MIT-licensed plugin that gives our Filament admin panel richer dashboard widgets out of the box. It buys back roughly one to three sprints of dashboard work on internal and back-office tooling, at essentially zero license cost and with no vendor lock-in — the code is ours to fork if the maintainer walks away. The 4.0.0 release is a maturity signal: it adds support for Filament v4 and RTL layouts, and it brought in outside contributors. The trade-off remains maturity — young package, small user base — so we'd use it for internal surfaces first, pin the version to match our Filament major, and keep a documented exit path. Recommendation: approve a short evaluation spike, not a platform-wide commitment, and sequence it alongside the Filament v4 upgrade rather than as a separate initiative.

For engineering: Filament-native widgets that extend the built-in Stat/Chart/Table primitives, so it composes with existing panels and Livewire patterns rather than introducing a second UI paradigm. Version 4.0.0 adds Filament v4 compatibility, RTL support on the stat widget, and a fix for labelColor/valueColor resolution — so the 4.x line is where active work lands and 3.x is effectively maintenance. Confirm your Filament major before touching Composer; the 3→4 package bump should ride the same branch as the Filament v3→v4 upgrade, not precede it. It's still a small dependency, which is both the appeal and the risk — expect to own compatibility with future Filament majors. Proposed guardrails: pin the exact major, add an internal wrapper layer so widgets are replaceable, cover dashboard rendering with a smoke/visual test (plus an RTL render case if we localize), and timebox the spike to validate against our current Filament and PHP versions before we design roadmap around it.