Jetstream Laravel Package

Product Decisions This Supports

• Build vs. buy for application substrate. Auth, account management, teams, roles/permissions, and audit logging are the recurring 6–12 engineer-weeks every Laravel SaaS pays before writing a line of differentiating code. This package is a candidate to convert that fixed cost into a one-time evaluation cost.
• Roadmap and launch-date commitments. If the substrate is bought, the MVP milestone can be re-baselined against domain features instead of login/registration/team-invite flows. This is the single largest lever the package offers a PM: it moves the critical path.
• Whether to keep Jetstream at all. The registry description calls this a "self-contained Jetstream successor" while the package's own description.md calls it a companion that bolts onto an existing Jetstream app. These are two different products with two different adoption costs. Resolving that contradiction is the first PM decision, because one path is a composer require and the other is an application-template commitment you may not be able to back out of cheaply.
• Compliance-adjacent feature scoping. Audit logging plus custom roles/permissions is frequently a sales gate, not an engineering nicety — it unlocks B2B deals that require access trails and role separation. Bundling it into the substrate means it can be promised on a roadmap earlier and with less schedule risk than a custom build.
• Platform standardization across multiple Laravel products. If you run or plan more than one Laravel app, adopting one substrate sets a convention (and a shared upgrade burden). Adopting nothing sets a different, more expensive convention: every team reinvents it.
• Pilot go/no-go framing. This is not a decision to adopt; it is a decision to spend 3–5 days finding out. Define the pilot's acceptance criteria up front — install time, files overridden, test-suite status, upgrade path from a pre-1.0 tag, and a security review of the auth/2FA/token paths — and treat the scorecard as the deliverable.

When to Consider This Package

Consider it when:

• The product is Laravel, and the team has not yet customized Jetstream scaffolding. That is the happy path and the only cheap one.
• You need teams, invitations, roles/permissions, and audit logging as a bundle, and you'd otherwise build all four.
• A 3–5 day spike is affordable relative to the 6–12 weeks of substrate work it might displace.
• Someone on the team is already fluent in Jetstream and can read the scaffolding diff competently.
• You're willing to own a periodic republish/re-merge cycle as a standing maintenance line item — not a one-time install.

Look elsewhere when:

• Adoption evidence is required. Zero stars and a single tag means there is no third-party production signal — no case studies, no issue history, no "who else runs this." For a decision of this blast radius, that is a real gap, not a vanity metric. If your org requires referenceable adoption, this fails today.
• You need the changelog to mean something. v1.0.0's release note is a commit-range link: no feature list, no breaking-change callouts, no migration guide, no support-window statement. A PM cannot put a version number in a launch plan when the contents of that version are unread.
• The existing app has customized Jetstream. Package-managed scaffolding plus project-customized scaffolding is a merge problem on every upgrade, and the failures land in auth and team-membership logic — the two places you least want silent regressions.
• Requirements exceed the scope. Enterprise SSO/SAML/SCIM, fine-grained ABAC, or formally documented compliance postures are not what this ships. Don't stretch it.
• The front-end stack isn't settled. Jetstream commits you to Livewire or Inertia (React/Vue). If design hasn't decided, this decision is premature and expensive to reverse.
• You can't get a security review. It touches auth guards, 2FA, and API tokens by inheritance. If nobody will sign off, the answer is no regardless of everything else.

How to Pitch It (Stakeholders)

To executives: This is a candidate to replace the boilerplate every Laravel product pays for — authentication, accounts, team management, role-based permissions, and audit trails — with something adopted in days instead of built in months. The upside is schedule: it moves the MVP's critical path onto features customers pay for, and it lets us promise audit logging and role separation, which specific B2B deals ask for. The honest caveats: it's a first release with no public track record, and the maintainer's own materials describe it two different ways — as a drop-in companion and as a full application template. That ambiguity is the reason for the ask. We are requesting a bounded 3–5 day evaluation, not adoption. The output is a scorecard — install cost, how much of our code it owns, security review, and upgrade effort — and a go/no-go at the end. No standardization decision is being made here.

To engineering: Read this as an application-substrate dependency, not a leaf library. It sits on top of or alongside Jetstream, which means it touches auth flows, session handling, and UI composition, and the swap-out cost later is high. Before we commit, we need four answers: does it replace published scaffolding, augment it via middleware/service provider, or ship a parallel stack; what's the tested Laravel/PHP/Livewire-or-Inertia matrix; what does the tag diff actually say; and what's the maintainer cadence and test coverage. Then a scratch-app spike and a diff against our current scaffolding to size the merge. If we adopt, we pin the exact version, write a one-page "these files are package-owned, do not edit" convention into the README on day one, and record the commit hash as our fork point.

To product and design: The value here is that team management, invitations, custom roles, and audit logging come as one package instead of four backlog items — that's real schedule returned to the roadmap. The cost is a stack commitment: Jetstream means Livewire or Inertia, chosen now, hard to revisit. Treat the pilot as a measurement exercise — track time-to-first-working-auth, defect rate in account and team flows through the first sprint, and the hours burned on the first upstream upgrade. Those three numbers tell us more about whether to standardize than any evaluation document will.