Filaprogress Laravel Package

Technical Evaluation

Architecture fit

• Ships as a standard Filament plugin (Composer package, service provider, Plugin contract, panel registration in AdminPanelProvider). That is the least intrusive extension point Filament offers — no route, middleware, or auth-layer surgery.
• The decisive architectural question is whether the package is presentational (computes progress from our existing data and renders a widget/Blade view) or stateful (ships migrations, models, and owns progress records). The description ("tracking and visualizing progress") is ambiguous on this point. Presentational = trivial to adopt and trivial to remove. Stateful = it becomes part of our schema and our exit cost multiplies.
• Surface area appears small (widgets + views), which is favorable: there is little room for it to impose conventions on our domain model.

Integration feasibility

• Mechanically low-effort: composer require, register the plugin on one panel, optionally publish config/views/assets. A competent Filament developer can produce a working spike in under a day.
• The absence of dependents and thin public adoption means no reference implementations, no community-sourced edge cases, and no signals about how it behaves under multi-tenancy, localization, or large datasets. We would be the primary integrator.
• Feasibility is gated almost entirely on Filament version compatibility, which must be verified from composer.json rather than assumed.

Technical risk

• Abandonment is the dominant risk, not code quality. Single maintainer, 34 stars, 0 dependents, last release 2024-09-03. Filament ships major versions with breaking plugin-contract changes; an unmaintained plugin becomes an upgrade blocker at the next major.
• Bus factor of one, no vendor, no SLA. Support is effectively "we read the source."
• MIT license removes legal friction; we retain the right to fork. That is the real mitigation.
• Risk is acceptable only if the package stays outside our persistence layer and the widget is feature-flagged.

Key questions to resolve before commitment

1. Does it ship migrations/models, or compute progress on read? (Determines exit cost.)
2. Exact Filament and Laravel version constraints in composer.json — does it support our current panel version, and the next one?
3. Does it ship compiled CSS/JS assets or require a consumer-side build? Are assets versioned correctly?
4. Is progress refreshed via Livewire polling? At what interval, and does each poll execute aggregate COUNT queries?
5. Does it respect Filament multi-tenancy and panel scoping, or leak data across tenants?
6. Test coverage and CI status?
7. Does it register globally or per-panel (i.e., can we scope it to one admin surface)?
8. Localization/translation support for user-facing strings?

Integration Approach

Stack fit

• Good fit if we are on Filament 3.x and the package's constraints align. Poor fit on Filament 4.x without verification or a fork. This is a binary gate — confirm before planning any work.
• Fits cleanly as an admin-panel-only concern. Keep it out of application/domain code entirely; no service should depend on the package.

Migration path

• Adopt additively: install into a sandbox or a non-critical panel first, register the plugin behind a feature flag, and confirm rendering against real data volumes before enabling broadly.
• If it ships migrations, run them in a scratch database first and diff the schema. Prefer to not let it own tables — if the feature can be delivered from existing data, configure it that way.
• Exit ramp is the design constraint: keep the widget behind a flag and keep our own thin wrapper (a single Blade partial or a small custom widget that delegates) so replacement is a one-file change. If the project dies, we rebuild a progress widget in a day or two — which reframes the entire decision.

Compatibility

• Verify PHP, Laravel, Filament, and Livewire constraints against our lockfile. Check that package assets do not conflict with our Vite pipeline or Tailwind theme.
• Check whether the plugin registers a Plugin object (Filament 3 style) versus older widget-only registration — this dates the code and predicts upgrade pain.

Sequencing

1. Compatibility check (hours): read composer.json, install in a throwaway Laravel/Filament app at our exact versions.
2. Capability spike (1–2 days): wire one widget against a realistic dataset; measure query cost and polling behavior.
3. Build-vs-buy call: the package's value ceiling is roughly "one custom Filament widget." If the spike shows friction, building it ourselves is likely cheaper over a 12-month horizon than owning an unmaintained dependency.
4. If adopted: pin an exact version, vendor/fork readiness documented, feature flag on, single surface rollout.
5. If not adopted: harvest the Blade/UX patterns (MIT permits it) and implement natively.

Operational Impact

Maintenance

• Steady-state maintenance is low — it is a small view-layer package. The real cost is event-driven: every Filament major upgrade requires us to verify or patch it. Budget roughly 1–2 engineer-days per Filament major, plus an owner for the fork decision.
• Pin the version exactly rather than floating; an abandoned package plus a floating constraint is how silent breakage enters a panel.

Support

• No vendor, no SLA, no support channel beyond GitHub issues on a 34-star repo. Assume issues go unanswered. Internal ownership must be explicit: name an owner in the repo, record the version, and note the fork procedure in the README or an ADR.

Scaling

• Admin panels are low-concurrency by nature; per-request overhead is negligible at typical admin traffic.
• The scaling concern is query cost, not request volume: progress calculations typically aggregate counts over large tables. Require indexes on the status/completion columns that feed any progress computation, and cap evaluation to filtered/scoped datasets rather than whole-table scans.
• If polling is enabled, verify the interval and that it does not re-run expensive aggregates per client. Set a sane interval or disable it in favor of manual refresh.
• If the package persists progress rows, watch write amplification on high-churn entities.

Failure modes and mitigations

• Silent breakage on Filament upgrade — blank widget, panel boot exception, or unstyled output. Mitigate: feature flag, class_exists guard around registration, post-deploy smoke test of the panel dashboard.
• Stale published assets after upgrade — mitigate: re-publish as part of the upgrade runbook.
• Migration collision if it ships migrations that conflict with our schema — mitigate: pre-flight schema diff in staging.
• Expensive aggregate queries degrading the dashboard as data grows — mitigate: index review and load test with production-scale row counts.
• Multi-tenancy leakage if scoping is not respected — mitigate: verify with two tenants in staging before enabling.

Ramp-up

• Hours for any developer already fluent in Filament. Negligible documentation burden beyond the README and a short internal note on configuration and the fork decision.
• The ramp-up risk is organizational, not technical: without an explicit owner, an unmaintained plugin becomes invisible debt that surfaces as a blocked Filament upgrade 12 months later.

TPM recommendation Treat this as a low-ceiling convenience, not a platform dependency. Its likely value is one progress widget; its likely cost is an unowned dependency tied to a fast-moving framework's major-version cadence. Proceed only if the compatibility check passes and the package remains presentational; otherwise copy the pattern under MIT and build natively.