Laravel Splade Breeze Laravel Package

Product Decisions This Supports

• Build vs. buy for authentication UI. This package is a scaffolding decision, not a runtime dependency decision: it generates controllers, routes, Vue pages, and migrations into your repo. That means the real question is "do we spend 3–5 engineering days hand-rolling auth screens, or do we start from a template?" — not "do we add a third-party dependency we'll carry forever."
• Framework standardization on Splade. If your stack decision is already "Laravel + Splade (Vue 3, no separate SPA/API)," this package answers the follow-on question of what the login, registration, password reset, email verification, and profile screens look like on day one.
• Time-to-first-demo / MVP scoping. Useful when the roadmap item is "ship a working authenticated app shell" and auth is table stakes rather than differentiation. Frees sprint capacity for the features that actually get evaluated.
• Baseline currency on modern Laravel. With 2.5.2 the generated scaffold is validated against Laravel 11 and PHP 8.3, so a greenfield app started on a current LTS-era stack doesn't begin with a known-stale template. That removes a common objection ("we'd be starting from pre-Laravel-11 code") from the scoping conversation.
• Feature completeness baseline. Gives a checklist of what "done" means for auth (throttling, verification, password confirmation, profile update) so you can scope cuts explicitly rather than discovering gaps mid-sprint.
• Use cases where it fits: internal tools, admin panels, prototypes and design partners, and greenfield apps where the team has already committed to Splade and wants consistency with existing Splade codebases.

When to Consider This Package

Consider it when all of the following hold:

• Splade is a locked-in architectural choice — not an experiment. This package is only coherent inside that ecosystem.
• Your target runtime is Laravel 11 / PHP 8.3 (the newest combination this release explicitly supports). On Laravel 12+ you are back to patching forward yourself.
• The team is small and auth is undifferentiated work you want to compress, not own from scratch.
• You're comfortable that the generated code becomes yours to maintain and upgrade. Archival status is tolerable precisely because scaffolding is copied in, not resolved from Packagist at runtime.
• You can accept the current feature set as a starting point; framework support now reaches Laravel 11, but nothing beyond it is promised.

Look elsewhere when:

• You aren't on Splade. Laravel Breeze, Jetstream, or the current official laravel new starter kits are the default answer, with vastly larger communities and active maintenance.
• You need long-term vendor assurance. The repo is archived, it has ~15 stars and zero dependents, and 2.5.2's non-dependency changes are limited to PHP 8.3 / Laravel 11 support plus Dependabot CI bumps — no feature work, no security process. Treat it as a reference implementation to copy from, not a supported product. No security advisories, no compatibility guarantees, no issue triage.
• You're already on Laravel 12 or later, or plan to be within the useful life of the product. The scaffolding will not track future framework releases.
• Auth is a compliance or security-critical surface (SSO, MFA, audit logging, regulated data). Scaffolding won't cover it, and you'd be layering custom work on an unmaintained base.
• You need community support or hiring leverage. Near-zero adoption means no Stack Overflow corpus, no tutorials, and no candidates who've seen it.
• You need MFA, teams/permissions, or API tokens out of the box — that's Jetstream/Breeze-with-extras territory.

If you proceed, treat it as a one-time template extraction with a mandatory internal review: read every generated file, pin Laravel 11 / Splade versions, and record an ADR noting that the code is now internally owned and that upstream will not patch beyond Laravel 11.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed starter template that gives us working login, registration, password reset, and profile screens on top of the Laravel/Splade stack we've already chosen. Its latest release (2.5.2) confirms support for Laravel 11 and PHP 8.3, so it isn't a stale starting point for a new build. It compresses what's typically several days of undifferentiated work into roughly a day of review and adaptation, so the team spends its first sprint on the product rather than on auth plumbing. The trade-off is that the project is archived and essentially unused in the wild — so we consume it as a template we copy and own, not as a vendor dependency. There is no ongoing runtime risk, no license cost, and no lock-in; the exit cost is zero because the code lives in our repository. Recommendation: approve for internal-tool and prototype use on Laravel 11, with a short engineering review before it touches anything customer-facing or regulated.

To engineering: Adopt as a scaffolding reference, not a dependency. Release 2.5.2 is a compatibility and housekeeping release — PHP 8.3 and Laravel 11 support from the maintainer, plus Dependabot bumps to CI actions (fetch-metadata, checkout, pint-action, git-auto-commit). No API or generated-file changes are implied, so prior review notes on throttle/verification/session behavior still apply. Vendor the generated code, pin Laravel 11 and Splade versions, and document the fork point. Budget half a day for review and expect to own upgrades yourself — upstream is archived and this release does not signal resumed maintenance, so there is no path to Laravel 12 without us doing it. If the review surfaces more than a day of rework, fall back to standard Laravel Breeze and adapt the views.