Breeze Laravel Package

Product Decisions This Supports

• Greenfield auth build vs. buy (time-to-first-value). Breeze answers "do we hand-roll registration, login, password reset, email verification, password confirmation, and profile update?" with a pre-built, framework-blessed baseline. Typical PM framing: days of auth work replaced by a single composer require laravel/breeze --dev plus an install command — release scope can skip auth entirely and go straight to product-differentiating features.
• Stack selection for the auth surface. Breeze offers Blade, Livewire, React/Inertia, Vue/Inertia, and an API-only (Sanctum) variant. This lets the stack decision be made on product grounds (team skills, SSR needs, mobile client needs) rather than on "which stack has working auth." The API stack is the notable one: it supports a decoupled frontend or a future mobile app without rewriting auth.
• Roadmap sequencing for MVP/internal tools. For internal tools, admin panels, and MVPs where authentication is undifferentiated, Breeze lets you defer investment in auth UX and revisit later — the code is yours to modify, so an "upgrade the auth experience" epic remains open rather than blocked.
• Build-vs-buy at the scope level: Breeze vs. Jetstream vs. Fortify vs. hand-rolled. This is the highest-leverage decision the package informs. Breeze = minimal, code you own and edit. Jetstream = heavier scaffolding with teams, 2FA, API tokens, and a maintained frontend stack. Fortify = headless auth backend if you want a custom UI. Laravel UI = legacy, avoid. A PM can use Breeze as the explicit "minimal viable" anchor in that comparison rather than defaulting to the most feature-rich option.
• Lock-in and exit-cost decisions. Because Breeze publishes code into your application instead of remaining a runtime dependency, adopting it has near-zero dependency risk and no version-upgrade treadmill for the auth layer. It's the low-commitment end of the buy spectrum — relevant when legal/procurement or architecture review asks about vendor dependency.
• Maintenance-mode and platform-version decisions (the important one). The README explicitly states the starter kit targets Laravel 11.x and prior and directs new work to the current official starter kits. That converts into a concrete portfolio decision: existing Breeze-based apps stay on the 2.x maintenance line (which continues to receive compatibility patches — Laravel 12 support in v2.3.5, Laravel 13 compatibility in v2.4.0, a Laravel 13+ bootstrap.js fix in v2.4.2); new products on Laravel 12+ should not start here.
• Support-burden forecasting. The changelog is dominated by dependency bumps (Vue plugin, Headless UI, Inertia v2, Tailwind, TypeScript, Pest/PHPStan), TypeScript type fixes, and minor UX corrections. For a PM this signals a surface that mostly needs periodic dependency hygiene rather than feature work — cheap to keep alive, but not a source of capability growth.

When to Consider This Package

Adopt when:

• You are on Laravel 11.x or earlier and need standard session-based auth quickly, with a UI you intend to customize.
• You want code you own rather than a black-box auth dependency — you're comfortable that "upgrading" means editing your own files, not bumping a version.
• The product's differentiation is not in authentication; you're optimizing for delivery speed on the core feature set.
• You need a minimal, readable reference implementation the team can extend (add SSO, add roles/permissions, swap the layout) rather than a batteries-included platform.
• An API-first or mobile-forward product needs token auth baseline — the Sanctum API stack is a legitimate starting point.
• You are prototyping or building an internal tool where auth polish is out of scope.

Look elsewhere when:

• You are starting a new project on Laravel 12 or later — follow the README and evaluate the current official starter kits instead. Building greenfield on a maintenance-mode scaffold is a decision you will have to reverse.
• You need teams/multi-tenancy, 2FA, API token management, or profile photo handling out of the box — that's Jetstream's scope, or you scope an explicit build on top of Breeze.
• You want a headless auth backend with a fully custom frontend — Fortify is the better fit.
• You need advanced auth product capabilities: enterprise SSO/SAML/OIDC, SCIM provisioning, fine-grained RBAC/ABAC, audit logging, or compliance-grade session policy. Breeze provides none of this and you'd be building it anyway.
• The org requires a vendor-supported SLA or security-patch commitment on the auth layer; a maintenance-mode, community-contributed starter kit does not provide that.
• Your team is not on the Laravel/Tailwind/Inertia toolchain — the value proposition is entirely framework-native.

Two data caveats worth stating plainly in any decision doc: the "0 dependents" figure is a measurement artifact, not a risk signal — Breeze is a --dev installer that copies files into your app, so it never appears in anyone's runtime dependency graph. And the composite score (~51) with opportunity at ~45 reflects a mature, widely-used, but strategically superseded package: high historical value, low remaining opportunity.

How to Pitch It (Stakeholders)

To executives (one paragraph): Laravel Breeze is a free, MIT-licensed scaffolding tool that generates a complete, working authentication layer — sign-up, sign-in, password reset, email verification, password confirmation, and profile editing — directly into our codebase in minutes. It is not a third-party service or a runtime dependency: it writes standard code into our application, so there is no recurring cost, no vendor lock-in, and no external data processor to review. Its strategic role is speed on undifferentiated work: it lets us spend engineering budget on the features customers actually pay for instead of rebuilding login screens. Important caveat: upstream now positions Breeze for Laravel 11.x and earlier and points new projects to the current official starter kits. So the recommendation is use it to accelerate and maintain the existing Laravel 11-and-earlier products; do not start new Laravel 12+ products on it — those should go through the current starter-kit evaluation.

To engineering (the ask): Standardize on Breeze as the auth baseline for the in-flight Laravel 11 projects, with the API/Sanctum stack where a mobile or decoupled client is on the roadmap. Treat the generated auth code as first-class, owned code — it lives in our repo and we extend it (SSO, roles, audit) on our own schedule. Expect the maintenance work to be dependency hygiene, not feature development; the 2.x line is still receiving compatibility patches (Laravel 12, Laravel 13), so existing apps are de-risked. In parallel, run a short spike on the current official starter kits so the Laravel 12+ migration path is defined before the next greenfield project kicks off. Budget the decision, not just the install: capture in the ADR why minimal scaffolding (rather than Jetstream's teams/2FA/tokens) matched our product scope, so a future "we need 2FA" request is a scoped extension rather than a re-platform.