Filament Simple Stats Laravel Package

Product Decisions This Supports

• Dashboard scope and time-to-value for internal tooling. This package is a delivery accelerator, not a product differentiator. It lets a team ship Filament dashboard stat cards (counts, sums, period-over-period trends) in a few lines instead of building custom widget + aggregation logic. PM framing: it compresses "we need an admin dashboard for the ops team" from a sprint-sized task to an afternoon, freeing roadmap capacity for customer-facing work.
• Build vs. buy on analytics surfaces. For early-stage internal dashboards, this is a clear "borrow" decision: MIT-licensed, Spatie-maintained, no licensing cost, no vendor contract, no data leaving your infrastructure. The build alternative (custom Filament widgets wrapping your own aggregation queries) is not hard, but it is undifferentiated work — reasonable to defer it until requirements exceed what this offers.
• Feature scoping for MVP admin panels. The opinionated API (last30Days(), dailyCount(), dailySum(), where(), withoutTrend(), invertTrendColors()) effectively defines the feature boundary of "simple stats." That is useful for saying no: if a stakeholder asks for cohort analysis, custom date-range pickers, or multi-series comparisons, that is a different (larger) feature, not a tweak.
• Metric definition and semantics debates. Trend display forces explicit product decisions that are often otherwise left ambiguous: period-over-period comparison windows, whether "today" is included (the changelog shows an explicit fix to include end-of-day data), and whether a decrease is good or bad. invertTrendColors() is a direct product lever for cost/error-rate/churn metrics where down is up. Use this as the forcing function to get metric owners to agree on directionality before the dashboard ships.
• Roadmap sequencing for "insight" requests. When a stakeholder asks for "analytics," this package is the cheap probe: ship three or four stat cards, measure whether anyone actually looks at them, and only then invest in a real reporting layer. It is a validated-learning tool as much as a UI library.

When to Consider This Package

Good fit when:

• You are already on Filament (this is a hard prerequisite — it is a widget set for that admin framework) and want dashboard stats now.
• Your metrics are single-model, simple aggregates: row counts, column sums, optionally filtered by a where clause. The where('user_id', auth()->id()) pattern covers the common "scoped to current user/tenant" case.
• You want trend indicators for free and are fine with the package's default period-over-period behavior and color conventions.
• Your stack tracks current Laravel and Filament releases — the changelog shows active support through Laravel 13 and Filament widgets 5.2, and 1.2.0 inlined flowframe/laravel-trend rather than depending on it, which meaningfully reduces supply-chain surface area.
• You value a permissive license and no lock-in: MIT, small footprint, trivially removable.

Look elsewhere when:

• You are not on Filament. There is no path here; a generic charting or BI tool is the right call.
• You need metrics beyond count/sum — averages, percentiles, distinct counts, ratios, retention, funnels, cohort breakdowns, multi-dimension grouping. The package is explicitly "opinionated," which here means deliberately narrow.
• You need user-configurable date ranges or filters. The periods appear to be preset methods (last30Days()), not an interactive picker. If stakeholders expect to explore data, that is a reporting product, not a stat widget.
• You need drill-downs, exports, scheduled email digests, or alerting. None of that is in scope.
• You need auditability or metric governance. These stats run against live Eloquent queries; there is no semantic layer, no caching strategy prescribed, and no definition registry. On large tables, an unindexed dailySum() on a dashboard that loads on every page view is a performance risk your engineering team must own. Ask specifically about query cost and caching before adopting on high-traffic admin panels.
• The signal matters. 28 GitHub stars and 0 dependents is thin social proof. The Spatie brand and release cadence carry real weight, but this is a small, single-maintainer-ish utility — not a load-bearing dependency. Avoid it where the dashboard is customer-facing or SLA-bound.

Adoption checklist for engineering: confirm Filament version compatibility, index the columns used in where and date-range aggregation, confirm whether trend queries double the query load per card, and confirm timezone handling for "daily" buckets (a recurring source of subtly wrong dashboards).

How to Pitch It (Stakeholders)

For executives: We can stand up the internal dashboard's headline numbers — new users, revenue, activity, error counts — in roughly a day of engineering instead of a sprint, using a free, MIT-licensed, Spatie-maintained component that runs entirely inside our own infrastructure. There is no vendor, no per-seat cost, and no data sharing. It gives us a cheap way to test whether the dashboard is actually used before we commit budget to a real reporting product. The trade-off is deliberate: it handles simple counts and totals with trend arrows, not custom analytics. If the business needs explorable, filterable reporting, that is a separate, larger investment — and this package helps us find out whether that investment is warranted.

For engineering: It is a thin wrapper combining Filament's native Stat widget with trend aggregation, configured declaratively inside an existing widget class (SimpleStat::make(Model::class)->last30Days()->dailyCount()). It supports where() scoping and Eloquent builders, and lets you disable trends or invert trend colors per card. As of 1.2.0 it inlines flowframe/laravel-trend and tracks current Laravel/Filament releases. It is small and easy to replace — the main things to verify before merge are index coverage on the aggregated columns and the per-page-load query cost, since each trend card implies a comparison-period query as well.