Nativekitv4 Laravel Package

Product Decisions This Supports

• Filament version lockstep: 4.14.0 aligns the starter kit with Filament v4.14.0. Any roadmap item assuming Filament v4.x features (admin panels, resource generators, form/table schema APIs) should be scoped against this pairing, not against Filament in isolation.
• Build vs. buy on admin scaffolding: The user/admin package split (PR #95) is the strongest signal here — models, Filament resources, and login flows now live in reusable packages rather than app-level code. That shifts the calculus from "fork a starter kit" toward "compose from packages," which is cheaper to maintain across multiple products.
• Multi-tenant / multi-panel roadmap: Because auth, user models, and resources are packaged separately, adding a second panel (e.g., customer vs. staff) becomes configuration, not a rewrite. This unlocks roadmap options for tiered admin surfaces without re-architecting.
• Upgrade-cadence planning: The release is dominated by CI and dependency hygiene (PHPStan on PHP 8.4, Dependabot groups for Composer and npm, pnpm overrides patching shell-quote and source-map-js). Treat the maintainer's cadence as a supply-chain signal: routine patching happens, so planning a quarterly Filament bump is realistic.
• Use cases: internal back-office CRUD, admin dashboards for SaaS MVPs, prototypes needing auth + resource scaffolding in days, and teams already on Filament who want a maintained baseline rather than hand-rolling panels.

When to Consider This Package

Adopt when:

• You are standardizing on Filament v4 and want scaffolding that moves in lockstep with it.
• You want auth, user/admin models, and resources as separable packages so the same foundation serves multiple apps or panels.
• You run or are willing to run PHP 8.4 in CI — the project's own static analysis targets it, so it's the well-tested path.
• Your team is comfortable owning the fork: this is a starter kit, so expect to diverge. A healthy CI/Dependabot setup reduces but does not remove that burden.
• You need a fast path to a working admin surface and would rather spend the first sprint on domain logic.

Look elsewhere when:

• You are on Filament v3 or earlier — the 4.14.0 versioning means the kit moves with v4; a migration is implied, not supported here.
• You need a hardened, security-audited auth layer with a published CVE process. The auth in this kit is scaffolding; production auth (password policies, MFA, session hardening) is still your build.
• Your stack is Vite/npm light or non-JS — the toolchain carries pnpm-workspace.yaml overrides and patched transitive JS deps that you'd inherit and must keep current.
• You require stable, documented public APIs with semver guarantees across the user/admin packages. The package split is recent (PR #95) and namespaces may still move.
• You are on Laravel versions outside the tested matrix — this release says nothing about Laravel support breadth, so verify before committing.

How to Pitch It (Stakeholders)

To executives: This is a maintained, low-cost foundation for our admin interface. The 4.14.0 release is a maintenance release — it keeps us current with Filament 4.14 and tightens the project's automated testing and dependency patching. The strategically relevant change is that user, admin, and login functionality now ship as discrete packages, which means we can reuse the same backbone for additional products and internal tools instead of rebuilding auth and CRUD screens each time. Net effect: faster time-to-first-screen and lower long-term maintenance per app.

To engineering: Pin to Filament 4.14.0; the kit versions in lockstep with it, so treat the two as a single upgrade unit. Verify the new user/admin package namespaces against any existing app-level models and resources before merging — PR #95 relocates models, resources, and login, so expect import churn and possible migration edits. CI now runs PHPStan on PHP 8.4 and Dependabot groups Composer and npm bumps; align our own pipeline with that, and note the pnpm overrides for shell-quote and source-map-js that we would inherit. No breaking API changes are called out in the notes, but the package extraction is a structural change — budget a spike to validate it rather than assuming a drop-in upgrade.