Filament Plugin Tools Laravel Package

Product Decisions This Supports

• Build-vs-buy for internal admin tooling — but one level up the stack. This package ships no customer-facing feature. It is the factory that produces the Filament plugins our teams use to build internal admin and ops panels. So the decision it actually informs is not "should we add this feature" but "do we standardize how we manufacture internal panels, or let each team hand-roll plugin structure?" That is a platform/DevEx capital decision, funded from tooling budget, not a roadmap line item.
• Developer-productivity roadmap. Adopting it commits us to a plugin architecture, naming conventions, and a specific Filament major version. Those are strategic choices with compounding downstream cost: onboarding time, code-review friction, and how cheaply we can stand up the next internal panel. The PM question is whether we want that consistency to be a policy or an accident.
• Package-portfolio economics. If the roadmap implies multiple in-house Laravel/Filament packages, this tooling is the lever on cost-per-plugin over a 12–24 month horizon — scaffolding hours, review cycles, and upgrade effort all scale with it. If we ship exactly one plugin, the tooling is ceremony that still has to be upgraded every time Filament bumps a major.
• Supply-chain hygiene as a scoreable input. Release 2.0.5 drops the illuminate/contracts requirement, modestly shrinking the transitive dependency surface — a small positive for our dependency-risk posture. But the same release carries a version-provenance inconsistency (a 2.0.5 tag whose changelog compares against a 3.0.0 baseline). That is a governance signal, and it blocks pinning in a shared template until resolved.
• TCO framing, not feature value. No conversion, revenue, retention, or reliability metric moves based on this decision. Evaluate it purely on engineering leverage and maintenance cost, and be explicit in the business case that the return is measured in engineer-hours saved per plugin, not in product outcomes.

When to Consider This Package

Consider it when:

• We are building three or more Filament plugins, or credibly expect to within the planning horizon. Below that threshold the scaffolding savings don't repay the added abstraction or the coordination cost of enforcing a shared standard.
• We want consistent plugin skeletons — service provider, config, assets, migrations, tests — so that code review and onboarding become predictable rather than dependent on which team wrote the plugin.
• The team is already committed to Filament on a Laravel version that overlaps the package's supported matrix, and we can pin that mapping explicitly.
• We want less dependency sprawl; the illuminate/contracts removal is directionally positive, though it must be verified on a clean install against our own constraints rather than assumed.
• We accept up front that generated code is owned by the consuming team, not by the package. If that boundary isn't written down, every upstream upgrade becomes a merge exercise across every plugin we've ever generated.

Look elsewhere or defer when:

• We ship a single plugin, or our plugins differ enough in shape that a shared generator would be worked around rather than used.
• Version alignment is unresolved. A 2.0.5 tag compared against a 3.0.0 baseline means we cannot confidently reason about what we'd pin. Treat this as an upgrade-path risk until the maintainer clarifies whether 2.x is an actively maintained backport line (e.g., for Filament v3) while 3.x targets a newer major — or whether a line moved backwards.
• We need SLAs, guaranteed support, or long-term maintenance commitments. This is single-maintainer community OSS (4 stars, 0 dependents, MIT) with no commercial backstop. Fine for dev tooling; unacceptable anywhere in the runtime request path. The mitigation to record is not a support contract but "we are prepared to fork" — the package is small enough that forking is a genuinely low-cost option.
• A first-party Filament/Laravel generator or a thin internal template repo covers the same need with fewer moving parts. Exit cost in that direction is a day, not a quarter.

Recommended gate: a time-boxed spike — one real, non-critical plugin built end-to-end on our actual Filament version, measuring setup time saved and confirming clean-install dependency resolution. Standardize only if the spike is positive and the 2.x/3.x question is answered.

How to Pitch It (Stakeholders)

For executives: This is developer tooling, not a product feature. Its value is speed and consistency in building internal admin interfaces — it lowers the cost of each additional panel and makes those panels easier to maintain over time. Cost is low, risk is low-to-moderate, and it is fully replaceable if it stops being maintained. Fund it from platform/DevEx budget rather than a roadmap line, and judge it on engineering leverage and total cost of ownership — explicitly not on customer-facing metrics, because there aren't any.

For engineering leadership: Adopt it as an internal standard only if we are committing to multiple Filament plugins — otherwise it's unused ceremony that we still have to upgrade. What it buys us is a repeatable plugin skeleton, which reduces review friction, shortens onboarding, and keeps generated output consistent across teams. Two caveats must clear before we pin it in a shared template:

1. 2.0.5 drops illuminate/contracts. Slightly smaller footprint, but we must confirm on a clean install that neither our code nor any in-house plugin relied on Contracts arriving transitively — composer why illuminate/contracts settles it in minutes. Filament almost certainly supplies it transitively, so real-world impact is likely small, but this is exactly the class of change that passes on the maintainer's machine and fails on a consumer's.
2. The release metadata is inconsistent — a 2.0.5 tag compared against a 3.0.0 baseline. We need the maintainer to confirm which line targets which Filament major before we standardize, and we should pin that mapping rather than float a ^ constraint on a package whose versioning we don't yet understand.

Recommendation: run a one-day spike, build one real plugin, measure setup time saved, verify Contracts resolution, then document a pinned version and the rule that generated code is owned by the consuming team. If the spike is negative or the version line stays unclear, fall back to a thin internal template repo — the exit cost is a day, not a quarter.