Filament Starter Kit Laravel Package

Technical Evaluation

Architecture fit

• Filament Starter Kit is a scaffolding artifact, not a runtime dependency. It bootstraps a Laravel 13 + Filament 5 application (auth, admin panel, permissions via Shield, media via Curator, impersonation), then the consuming team owns and diverges the code. Treat it as a template repository, not a Composer library you track.
• v1.2.0 aligns the kit with a full-stack opinionated baseline: Laravel 13, PHP 8.3+, Filament 5, Pest 5, PHPStan (level max), Rector, Pint, Vite/Tailwind/Playwright. This is a coherent, modern "golden path" — good fit for greenfield internal tools, admin back‑offices, and CRUD-heavy backends.
• Poor fit if the target product is API-first, non-admin-facing, or pinned to older framework lines for compliance/hosting reasons.

Integration feasibility

• High for greenfield: composer create-project equivalent plus a documented quality gate suite. Low-to-moderate for brownfield adoption — you would be porting selected files (models, Filament resources, policies, test harness) into an existing app rather than merging.
• The release introduces a hard ecosystem bump (Laravel 13, PHP 8.3+, Filament 5, Pest 5, laravel/tinker ^3.0, nunomaduro/pao → laravel/pao). Every one of these is a major-version boundary. Feasibility hinges on whether our dependency set (auth providers, queues, storage, observability packages) has caught up.

Technical risk

• Bleeding-edge framework risk (high). Laravel 13 is a new major line; PHP 8.3 is the floor. Managed runtimes (Forge/Vapor/Cloud/Heroku buildpacks), CI images, container base images, and static-analysis tooling may lag. This is the dominant risk, and it is a platform risk, not a package defect.
• PHP version ambiguity (medium-high). Release notes state min PHP ^8.3 while also referencing "PHP 8.4/Laravel 13" attributes (#[WithoutIncrementing], #[Fillable], #[Guarded], #[Table]). If any of those attributes are 8.4-only, the declared floor is wrong and CI will fail on 8.3. Must be verified against composer.json platform config before planning.
• Filament 5 plugin triad (medium). Curator, Shield, and Impersonate must all be on Filament 5-compatible majors. Shield in particular carries permission/role migration implications; mismatched majors are the most common source of silent breakage here.
• laravel/pao substitution (low, positive). First-party replacement of an abandoned package is a supply-chain improvement, but verify API parity — "replacement" packages sometimes drop behavior.
• Starter-kit drift (medium, ongoing). No migration guide is offered. Teams on v1.1 have no supported upgrade; the only paths are cherry-pick or re-scaffold.
• Positive signal: 360 tests / 1,076 assertions passing with 0 skipped, PHPStan level max clean, Pint and Rector clean. That is a credible, verifiable quality bar and a strong argument for adopting the test harness even if you adopt nothing else.

Key questions

1. Is the true minimum PHP 8.3 or 8.4? Check composer.json and CI matrix; this decides whether our images need rebuilding.
2. Which exact majors of Filament, Shield, Curator, and Impersonate are pinned, and are any still in beta/RC?
3. Is there a documented v1.1 → v1.2 upgrade path, or is this a re-scaffold-only release?
4. What is the Laravel 13 support window, and what is the kit's own release cadence and bus-factor (single maintainer vs. team)?
5. Does the kit make assumptions about hosting (queue driver, storage disks, uploads_tmp path) that conflict with our target environment?
6. What is the license, and is commercial support available or expected?
7. Does the Playwright/E2E layer assume a specific CI runner and browser availability?

Integration Approach

Stack fit

• Strong fit where the target is a Filament-based admin/back-office on Laravel with a relational DB, and where the team already writes Pest tests and values static analysis.
• Weak fit for teams standardized on PHPUnit (Pest 5 is a disruptive re-tooling), on Laravel 11/12 LTS, or on a JS-heavy SPA frontend — the kit's Blade/Livewire/Tailwind assumptions will fight that architecture.
• The PHPStan-max + Rector + Pint trio is the most portable and lowest-risk piece: it can be adopted into existing repos independently of the rest of the kit.

Migration path

• Greenfield: scaffold from v1.2.0, pin the lockfile immediately, commit the generated baseline, and run all four quality gates in CI on day one.
• Brownfield: do not attempt a merge. Extract selectively — Eloquent models with the new attribute style, Filament resources, request validation classes, the Pest + PHPStan configuration, and the Playwright setup. Treat the kit as a reference implementation.
• From v1.1: expected path is re-scaffold into a side branch and diff, cherry-picking config and test-harness changes. Budget real effort here; there is no supported upgrade tooling.

Compatibility

• Verify in this order: PHP runtime availability in CI and production images → Laravel 13 in our dependency graph → Filament 5 compatibility of every installed plugin → Shield/Curator data migrations → Node/Vite/Tailwind build parity.
• Confirm the uploads_tmp disk change does not collide with our existing filesystem config or the Laravel 13 server-disk route; this is called out as a fix, implying it was a real conflict source.

Sequencing

1. Spike (1–2 days): scaffold in a throwaway repo, run the full quality gate suite, confirm the PHP floor on our actual CI image.
2. Dependency audit (2–3 days): resolve Filament 5 plugin compatibility and Shield migration implications against our stack.
3. Decision gate: if PHP 8.4 is required or a plugin is still prerelease, defer and pin v1.1 for now.
4. Pilot (1 sprint): build one real internal tool end-to-end; measure time-to-first-CRUD against our current baseline.
5. Standardize: publish an internal template repo + upgrade policy, and freeze the kit at v1.2.0 so future upstream changes are deliberate, not automatic.

Operational Impact

Maintenance

• Once scaffolded, the code is ours. Upstream releases are inspiration, not upgrades — this is the single most important operational fact and should be stated explicitly to stakeholders. There is no composer update path that keeps us aligned with the kit.
• Framework majors (Laravel 13, Filament 5) reset our own upgrade clock. Adopting early means we absorb ecosystem instability for roughly the first quarter of the line's life; adopting late means a compressed window before the next major.
• The generated composer.lock and the PHPStan/Rector/Pint configs are the durable assets; treat them as the version-controlled contract.

Support

• No evidence of commercial support or an SLA. Expect community-only channels. Assign an internal owner (a senior PHP engineer) as the de facto maintainer of our fork before the pilot starts.
• nunomaduro/pao → laravel/pao reduces one supply-chain support gap; confirm the maintainer's release cadence and whether the old package's docs/issues are still the de facto reference.

Scaling

• Runtime scaling is largely framework/Filament-driven, not kit-driven. The kit's opinions matter indirectly: Filament admin panels are Livewire-based and server-rendered, so admin concurrency is a PHP-worker and DB-query concern, not a CDN concern.
• Shield's role/permission model is the most likely scaling friction point — policy proliferation and permission-table growth become a governance problem at team scale. Budget for a permission-naming convention early.
• PHPStan level max and Rector will slow PR throughput slightly and reduce defect rate; plan onboarding accordingly rather than relaxing the gates.

Failure modes

• PHP floor mismatch: declared 8.3 vs. observed 8.4-only attributes → CI red on day one. Highest-probability, lowest-cost-to-detect failure. Verify first.
• Filament 5 plugin skew: Curator/Shield/Impersonate on incompatible majors → silent admin-panel breakage, permission regressions after deploy. Pin exact versions and lock the plugin set together.
• Ecosystem lag: PaaS/container/CI images without PHP 8.3+ or Laravel 13 support → deployment blocked late in the cycle.
• Upstream drift: teams assuming they can "pull latest" from the kit and discovering the tree has diverged beyond merge.
• uploads_tmp disk regression: temporary uploads colliding with the Laravel 13 server-disk route — verify file upload and download flows in staging, not just tests.
• Test-harness false confidence: Pest 5 assertion changes can mask behavioral differences; the Rector assertion modernization is convenient but should be reviewed, not auto-merged.

Ramp-up

• Filament + Livewire + Tailwind: ~1–2 weeks for a Laravel-comfortable engineer; Pest fluency is a fast follow.
• Shield (permissions) and Curator (media) are the two steepest curves and the two most operationally consequential components — assign deliberate ownership.
• PHPStan level max + Rector is a genuine cultural change, not a tooling change. Expect 2–3 sprints before the team stops fighting the static analyzer, and budget review time for the first Rector passes.
• Net: a small team can be productive on a scaffolded app within two to three weeks, provided PHP version and plugin compatibility are settled before the pilot begins.