Base Laravel Package

Product Decisions This Supports

• Build vs. buy for internal back-office tooling. The real decision isn't "should we add a dependency" — it's "do we scaffold our next admin panel from a curated Laravel + Filament starter, or assemble auth, user management, panel wiring, tests, and CI ourselves?" This repo answers the second option with roughly a day of setup instead of several weeks. Frame it as a template procurement decision, not a library adoption.
• Standardization of internal tooling. Choosing one base for all admin surfaces gives you consistent auth, user model, test and CI conventions, and static analysis. That's a governance call with long-run cost implications — it belongs in a platform decision record, not a per-project ticket.
• Roadmap and release-cadence import. Adopting this base imports Filament's release train into your roadmap. The 3.3.x version line mirrors Filament's version, not this package's own API contract, so "patch releases" arrive frequently and are not semver guarantees. Budget recurring maintenance time accordingly.
• Toolchain commitments that leak into the team. Release 3.3.56 moves the frontend build from pnpm to bun. That is a team-wide developer-environment commitment, not a user-facing feature, and should be approved as such before it spreads across forks.
• Vendor and ecosystem risk. Two GitHub stars and a contribution history dominated by one maintainer plus Dependabot is a strong signal that this is not a vendor dependency. It supports the decision "fork it and own it," not "rely on it being patched."
• Security and patch hygiene. 3.3.56 is almost entirely dependency bumps and CI housekeeping. The product value is risk reduction — the baseline isn't stale, and PHPStan runs on PHP 8.4 in CI — not new capability. Treat it as a maintenance signal when prioritizing whether to spend a sprint absorbing it.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel application whose primary surface is an admin panel, and Filament v3 is already the team's UI direction.
• You are prepared to fork it and own it — treat the repo as a template snapshot, not an upstream you track release-by-release.
• You want an opinionated baseline that already includes auth, a user resource, tests, PHPStan, and PHP 8.4 compatibility work.
• Your team is comfortable with a bun-based frontend build, or you can afford a short migration to it.

Look elsewhere when:

• You need a versioned dependency with a support contract. The 3.3.x numbers track Filament, so a patch bump can still contain a scaffold-level behavioral change (as 3.3.56 does with the filament-user swap).
• Your product is API-first or customer-facing — the value here is concentrated in admin CRUD scaffolding.
• You need a broad contributor base or commercial backing. With two stars and effectively one maintainer, assume self-support for anything outside core Filament.
• You only want Filament. Installing Filament into a plain Laravel app is cleaner than cloning a starter and deleting user-model, workflow, and tooling choices you didn't ask for.
• Your stack does not match the stated baseline. Metadata says Laravel 13.x; the release notes and prior technical review point to Laravel 11/12 + PHP 8.3/8.4. Resolve that discrepancy before committing — an ambiguous platform floor is a roadmap risk, not a detail.

Two caveats specific to 3.3.56: there are no breaking changes for consumers, but the user model, user resource, and login now delegate to filament-user — verify that matches your auth requirements before rebasing a fork. The pnpm→bun switch and PHPStan-on-8.4 work are toolchain-only.

How to Pitch It (Stakeholders)

Executives: This is a starting template for internal admin tools. It compresses the first several weeks of an internal build — login, user management, CRUD screens, CI — into roughly a day, and standardizing on one base lowers long-run maintenance cost across the portfolio. The risk is concentrated maintenance: with two stars and essentially one maintainer, this is not a vendor product we can expect to be patched. We should adopt it as a codebase we fork and own, with a named internal owner and a small recurring maintenance budget, rather than as a dependency we rely on. Recommendation: approve as a starting point for the next greenfield admin build, contingent on a named owner and a spike to confirm the platform baseline.

Engineering: Laravel + Filament v3 starter with auth, a user resource, tests, PHPStan, and PHP 8.4 in CI. Release 3.3.56 is housekeeping — Dependabot bumps, CI workflow standardization, one new maintainer — with no breaking changes. Three things to settle before forking: (1) the user model, user resource, and login now come from filament-user, so confirm it aligns with our auth and policy requirements; (2) frontend builds moved to bun, which is a developer-environment change needing sign-off and updated onboarding docs; (3) the version line tracks Filament upstream, so we should pin at fork time and manage upgrades deliberately rather than tracking releases. Suggested sequencing: pin, diff the scaffold against our conventions, cherry-pick the low-risk dependency bumps, pilot bun in one non-critical environment with a documented rollback, then decide separately on filament-user via its own ADR — it touches the auth boundary and is the highest-blast-radius item in the release.