Auth Laravel Package

Product Decisions This Supports

• Build vs. buy (adopt) for authentication. Every Laravel product needs login, registration, password reset, and email verification before it can monetize anything. This package turns that from a multi-sprint engineering workstream into a scoped integration task, freeing the team to spend its budget on the features customers actually pay for.
• Roadmap sequencing and dependency mapping. Auth is the upstream dependency for billing, teams/seats, permissions, audit logs, and onboarding. Choosing a foundation now determines how quickly those roadmap items can start — and how much rework happens when requirements (SSO, 2FA, invitations) arrive later.
• Feature scoping for v1. The package's out-of-the-box capability set becomes your baseline. Anything beyond it — social login, magic links, 2FA, org-level roles — converts into explicit, estimable roadmap items rather than vague "auth stuff" hidden in an epic.
• Use-case prioritization. Strong fit for MVPs and time-boxed validation, internal tools, agency/client builds, and Laravel SaaS scaffolds where speed-to-first-user dominates. Weak fit for regulated, enterprise-identity-heavy products — a decision worth making once, explicitly, at the portfolio level.
• UX and brand tradeoff. The package ships opinionated Blade/Tailwind views. That's a design decision you're implicitly accepting: either budget a restyle, or treat the views as a reference implementation and own the front end. Decide which before engineering starts, not after. Note that v2.2.0 moved the shipped views to Tailwind CSS v4, so the restyle budget now includes a CSS toolchain migration if the rest of your design system is still on v3.
• Standardization across the portfolio. If multiple Laravel products are in flight, choosing one auth foundation reduces context-switching, shared security review cost, and onboarding time for new engineers.
• Vendor/ecosystem posture. MIT-licensed, Laravel-native, no per-MAU or per-seat fees. This is an "own the code" decision, not a subscription decision — which is attractive financially and shifts maintenance responsibility onto us.

When to Consider This Package

Green lights — adopt when:

• The product is a Laravel application with a server-rendered or Blade/Tailwind front end, and needs conventional email/password auth flows.
• The team is small, the timeline is aggressive, and "auth in days, not sprints" is worth more than perfect architectural fit.
• You're comfortable owning the code: it's MIT and vendored into your repo, so security patching, upgrades, and customization are your responsibility, not a vendor's.
• The auth UI is not a differentiator (it almost never is) or you're willing to restyle it.
• Your front-end toolchain is on, or can move to, Tailwind CSS v4. As of v2.2.0 the shipped views assume v4. On a v3 codebase this is a migration item — not a blocker, but it belongs in the estimate, and running both major versions in a single build is friction you don't want.
• You want a readable, forkable starting point — lighter and easier to reason about than a full stack like Jetstream when you don't need the surrounding scaffolding.
• You have an engineering spike budget for a code review, integration tests around login/reset/verification, and version pinning before it touches production.

Look elsewhere when:

• Enterprise identity is on the 6–12 month roadmap. SAML/OIDC SSO, SCIM provisioning, tenant-level policies, and MFA enforcement belong with Fortify plus a dedicated identity provider (WorkOS, Auth0, Okta). Retrofitting these onto a starter package is a rewrite, not an extension.
• The product is API-first or mobile-first. Sanctum/Passport and token-based patterns are the right foundation; server-rendered auth scaffolding will be discarded.
• Authorization is complex. Multi-tenant role hierarchies, fine-grained RBAC/ABAC, or per-resource policies need deliberate design — pair with Spatie Permission or similar rather than assuming auth scaffolding covers it.
• Compliance and auditability are hard requirements. SOC 2 evidence, pen-test history, coordinated CVE disclosure, and a named security owner are things a package with a small maintainer footprint and limited dependents may not provide. Treat a security review as a gate, not a formality.
• This is a long-lived platform, not a prototype. A mid-hundreds star count and near-zero dependents is a real signal about ecosystem depth and bus factor. Breeze/Jetstream/Fortify have larger communities and first-party alignment with Laravel's release cadence. If maintenance risk outweighs speed, choose the well-trodden path.
• You need first-party support guarantees. MIT gives you rights, not a support contract.
• You need the auth views to stay on Tailwind v3 and can't absorb a toolchain upgrade — pin v2.1.1 and accept that you're off the current path, or own the views outright.

Mitigations to require if adopted: pin the version (v2.1.1 vs. v2.2.0 is a real fork in the road now — pick deliberately), read and own the code, add integration tests around every auth flow, confirm the Tailwind v4 migration cost against your existing design system before committing to v2.2.0, document an exit plan (it's routes, controllers, views, and migrations — swappable), and schedule a security review before public launch.

How to Pitch It (Stakeholders)

For executives: "This is an MIT-licensed Laravel authentication package. It gives us login, registration, password reset, and email verification in days instead of weeks, with no per-user or per-MAU fees and no vendor lock-in — the code sits in our repository and we can replace it. The tradeoff is that we own the maintenance and security hygiene of that code, so we'll run a short hardening sprint and a security review before launch and keep a documented exit path. The latest release (v2.2.0) is a styling-toolchain upgrade to Tailwind CSS v4 — no new auth features, no security changes, but it may add a small front-end migration cost if our other products are still on v3, so we'll scope that before choosing a version. Net effect: earlier time-to-first-customer, roughly one to three engineering weeks returned to differentiating work, and no recurring identity spend at our current scale. It is not the right choice if enterprise SSO or compliance certification lands within the year — in that case we'd go with the standard Laravel tooling plus a dedicated identity provider, and I'd want that decision made now rather than later."

For engineering: "Opinionated auth scaffolding — routes, controllers, views, migrations — designed to be forked and owned rather than configured from the outside. Faster than building from scratch; lighter than Jetstream if we don't need the whole stack; less ecosystem depth than Breeze/Fortify, so we treat it as code we now maintain. v2.2.0 is a single chore change: the views moved to Tailwind CSS v4, which is a breaking upgrade for anything that consumed the old v3 config or custom theme layer. Before merge: pick and pin a version deliberately (v2.1.1 if we're staying on v3, v2.2.0 if we're ready to move), review every line of the auth flows, wrap login/reset/verification in integration tests, confirm the upgrade story, and confirm the UI/restyle cost including the Tailwind migration. Treat the front-end as ours regardless — the views are a reference implementation. Escalate immediately if SSO, SCIM, or MFA enforcement appear on the roadmap — that changes the recommendation to Fortify plus an identity provider."

Decision requested: approve this as the v1 authentication foundation, contingent on one hardening sprint (code review, tests, security scan), an explicit Tailwind v3-vs-v4 version decision, and a documented fallback path. Instrument time-to-auth and hours saved so we can validate the bet against our next product build.