Installer Laravel Package

Product Decisions This Supports

• Feature scoping for admin/back-office work. The package's value is concentrated in the Filament admin layer, so it directly informs how fast we can ship internal tooling, CRUD screens, and operator-facing dashboards without bespoke Blade/Livewire work.
• Build vs. buy for admin surfaces. With Filament v4 support now in place, the calculus shifts: adopting gives us a maintained integration aligned to the current Filament major rather than a fork or in-house glue layer. Decide per-surface — buy for commodity CRUD, build where the workflow is a differentiator.
• Roadmap timing and platform currency. v0.0.4 signalling Filament v4 means the package is tracking upstream majors. That constrains when we can take Filament v4 upgrades elsewhere in the stack — a cross-cutting dependency decision, not a local one.
• Use cases worth validating in discovery: admin panels on Filament v4, resource/relation management, and any workflow where the package removes boilerplate versus a hand-rolled implementation.

Caveat for planning: this is a 0.0.x release. SemVer puts no stability guarantee on the public API, and the release note is a single line ("Filament v4") with no migration guidance. Treat all estimates that depend on this package as provisional until we've read the changelog and diff.

When to Consider This Package

Adopt when all of the following hold:

• We are on, or committed to, Filament v4. If any product surface is still on Filament v3, confirm whether v3 remains supported — a "Filament v4" release in a 0.0.x line is a plausible signal that v3 support was dropped, not merely joined. Verify before committing.
• The functionality it covers is adjacent to our differentiator, not the differentiator itself. Boilerplate removal is a good trade; core workflow logic is not.
• We can absorb pre-1.0 churn. Budget for pinning an exact version and for a migration pass on each minor bump.
• Someone owns upgrade tracking — Filament majors move, and this package's release cadence is now coupled to them.

Look elsewhere when:

• We need stability guarantees, an LTS, or a support contract. 0.0.x is the wrong risk profile for a revenue-critical path.
• We're on Filament v3 with no near-term v4 plan — the upgrade cost lands on us with no offsetting benefit.
• The surface area is small enough to hand-roll. A package dependency plus upgrade tracking can cost more than the boilerplate it saves.
• We need documentation depth or a community to lean on. One-line release notes suggest thin docs; validate forum/issue activity before betting a roadmap item on it.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is a small, pre-1.0 Laravel package that plugs into Filament, the admin-panel framework our internal tools are built on. The new release adds support for Filament v4, the current major version, which is the main thing we needed before it was usable. The upside is speed: less custom code for back-office screens, and one less thing to maintain ourselves. The risk is maturity — it's at version 0.0.4, which by convention means the interface can change without notice, and the release note is a single line with no migration guidance. Recommendation: approve it for internal admin tooling on a pinned version, not for customer-facing or revenue-critical paths, and revisit once it reaches 1.0 or we've run it through a release cycle.

For engineering — the asks:

1. Confirm whether Filament v3 is still supported or was dropped in this release, and read the actual changelog/diff behind the one-line note.
2. Pin an exact version in composer.json; do not float ^0.0.
3. Identify every surface currently on Filament v3 that would block or be blocked by this upgrade.
4. Timebox a spike against one real admin surface — measure the boilerplate actually removed before we commit roadmap capacity.
5. Flag the upgrade-tracking owner, since this package's release cadence is now tied to Filament majors.