Jetstream Laravel Package

Product Decisions This Supports

• Build vs. buy on account infrastructure. Jetstream is a code-generation starter kit, not a runtime dependency: jetstream:install writes auth/account actions, models, migrations, Tailwind views, and tests directly into your app for the Livewire or Inertia (Vue/React) stack. You are buying a blueprint and owning the building — which removes the classic "SaaS boilerplate lock-in" objection but replaces it with permanent in-house ownership of security-sensitive code.
• Scope decisions on table-stakes features. It bundles registration, login, email verification, password reset/confirmation, two-factor authentication, profile photos, API tokens (Sanctum), browser-session management, account deletion, and optional teams with invitations and roles. That is a concrete checklist for "what we do not need to design, spec, or estimate this quarter."
• Roadmap sequencing. It validates deferring differentiated work: teams/roles and 2FA are commoditized, so roadmap time is better spent on your domain logic, onboarding, and billing rather than auth screens. Conversely, it gives you a defensible "we can ship an invite-a-teammate flow in week one" commitment.
• Time-to-first-demo and pricing/packaging experiments. A working multi-user product with roles and invitations lets you test paid-tier boundaries (seats, team limits, API access) before committing engineering to a bespoke permission model.
• Stack standardization. Committing to Jetstream effectively commits the team to Tailwind + Livewire or Inertia, and pulls in Fortify (auth backend) and Sanctum (tokens). That is a hiring, code-review, and design-system decision as much as a feature decision.
• Maintenance budgeting. Because installed files are copied rather than upgraded via Composer, upstream fixes (e.g., the v3.1.1 two-factor challenge page reload fix) must be manually diffed and applied. PMs should plan a recurring "security patch triage" line item, not assume composer update covers it.

When to Consider This Package

Adopt when:

• You are on Laravel 11.x or earlier — the README explicitly scopes the kit to "Laravel 11.x and prior," so this is the deciding constraint.
• You are building an authenticated B2B or team-based SaaS where teams, invitations, and roles are genuinely needed, not speculative.
• You want the account layer owned in-repo — for compliance review, deep customization, or a design system the scaffolding will be forked into anyway.
• Your team is Laravel-fluent and comfortable owning auth code; you have capacity for periodic upstream diffing.
• You need a fast internal prototype or MVP where 4–6 weeks of account-UI work is the difference between a demo and a discovery conversation.

Look elsewhere when:

• Greenfield on Laravel 12+. Laravel now points to its current starter kits (https://laravel.com/starter-kits). Starting a new product on a kit that self-describes as "for Laravel 11.x and prior" is a roadmap liability, not a head start.
• You only need the auth backend with no UI opinion — use Fortify directly; or want minimal Blade views — use Breeze.
• You need enterprise identity: SSO/SAML, SCIM provisioning, audit logs, fine-grained policy-based RBAC. Jetstream's teams/roles are a starting point, not an authorization platform.
• You need true multi-tenancy (per-tenant databases, isolation, billing) — teams ≠ tenancy; evaluate dedicated tenancy packages or a SaaS boilerplate with billing.
• You are API-only, non-Laravel, or heavily brand-differentiated on the marketing surface where the Tailwind scaffolding will be discarded.
• Your team is not Laravel-fluent: the "you own the stubs" model becomes a maintenance trap rather than a shortcut.

Signals from the repo to weigh: releases continue, but the changelog cadence (v3.1.x: unused-import cleanup, a v-show removal, a typo fix, Pest 2 adoption) is maintenance-scale, not feature-scale. Treat this as a stable, low-velocity component. That is fine for a legacy app; it is a poor bet as the foundation of a 3-year roadmap.

How to Pitch It (Stakeholders)

To executives: Jetstream is Laravel's official Tailwind scaffolding for the account layer — sign-up, login, email verification, two-factor auth, profile management, API tokens, and team invitations with roles. Adopting it converts several weeks of undifferentiated engineering into an install command, with no license cost (MIT) and no vendor lock-in, because the generated code lives in our repository. The honest caveat: the maintainers now scope it to Laravel 11.x and prior and point new projects to Laravel's newer starter kits, so this is a "finish and stabilize existing products" investment, not a bet for new greenfield work. Recommendation: use it where we are already on Laravel ≤11 and need teams quickly; do not select it as the foundation for net-new products on the current Laravel release.

To engineering: It's a scaffolding generator, not a dependency — jetstream:install writes actions, models, migrations, Tailwind views, and Pest/PHPUnit tests into our app for the Livewire or Inertia stack, backed by Fortify (auth) and Sanctum (tokens). We own the code and the upgrade path: upstream fixes arrive as diffs we apply ourselves, so budget maintenance time for auth-touching changes. Expect to rework the views for our design system and to extend teams/roles well beyond what ships. Velocity is high for the first month; the cost shows up as long-term ownership of security-sensitive code that no composer update will patch for us.