Boilerplate Laravel Laravel Package

Product Decisions This Supports

• Build vs. buy for the SaaS substrate. This package is a "buy" answer to a narrow but expensive question: do we hand-roll authentication, teams, billing hooks, an admin panel, and social login for a new Laravel product, or start from an opinionated scaffold? It lets you price the alternative in engineer-weeks rather than guess at it.
• MVP scope and time-to-first-customer. Committing to a boilerplate is a roadmap decision: it moves the launch date forward by absorbing the undifferentiated 20–30% of a SaaS (auth, roles, admin CRUD, account settings) and lets the roadmap start at the actual product differentiator instead of at login screens.
• Admin/back-office strategy. Filament 5 + Livewire 4 is a specific bet — server-driven UI, no separate SPA for internal tooling. That decides who builds internal tools (full-stack PHP devs vs. front-end specialists), how fast support/ops tooling ships, and whether back-office work competes with customer-facing work for the same engineers.
• Identity and account model. Jetstream (teams, profiles, API tokens, 2FA) plus Sociallite (social/OAuth login) pre-commits you to an account/tenancy shape. Adopting it is easier than retrofitting teams or social login after customers exist, so this is a decision to make deliberately at inception, not later.
• Framework upgrade timing. The package pins Laravel 13, PHP 8.5, Filament 5, Livewire 4. Choosing it means choosing to track those majors on someone else's cadence. That's a standing roadmap constraint (upgrade windows, regression budget), not a one-off decision.
• DX and AI-assisted development posture. The bundled agents/AGENTS.md describes a Podman-based dev environment (lerd) with an MCP server, per-branch worktrees, and per-branch subdomains. That is a real input to the "how do we onboard engineers and use coding agents safely" decision — including whether preview environments per branch are a product capability you get for free.
• What it does not decide: pricing model, positioning, data/analytics stack, or anything customer-visible. Treat it as infrastructure, not strategy.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel SaaS and the first release is gated on auth, teams, account management, and an admin panel.
• Your team is already fluent in the TALL stack (PHP, Laravel, Livewire, Filament). The scaffold's value collapses if the team has to learn the stack and the boilerplate simultaneously.
• You need an internal/back-office surface early — support tooling, content moderation, tenant management — and don't want to fund a second front-end app for it.
• You want a container-first, agent-friendly dev workflow out of the box and value per-branch environments for review and QA.
• You are comfortable owning a fork. MIT licensing means you can vendor it, but it also means you own every upgrade.
• You are willing to run a timeboxed spike (e.g., two weeks, one engineer) to validate the fit before it becomes a dependency.

Look elsewhere when:

• You need a vendor with an SLA, security review, or indemnity. There is no commercial support here; 204 stars and a low opportunity signal mean a small community and thin third-party knowledge base.
• Your product is API-first, headless, or non-Laravel. Nothing here transfers, and the Livewire/Filament bet actively works against a decoupled front end.
• You have an existing application. Retrofitting a scaffold is usually more expensive than building the missing pieces in place.
• Upgrade velocity is a risk you can't absorb. Bleeding-edge pins (Laravel 13, PHP 8.5, Filament 5, Livewire 4) mean you inherit major-version churn. If you can't staff a recurring upgrade budget, a conservative, well-trodden starter is cheaper over 24 months.
• You have compliance, audit, or data-residency constraints that require documented control ownership. You'd be accepting an unaudited baseline and would need to review every line anyway.
• You need multi-tenant data isolation as a first-class feature — verify this explicitly rather than assuming a SaaS boilerplate implies tenancy architecture.

How to Pitch It (Stakeholders)

For executives — one paragraph: This is an MIT-licensed Laravel SaaS starter that hands us the plumbing every subscription product needs — sign-in, teams, account settings, an admin console, and social login — on a current framework stack. The case for it is schedule: it converts several engineer-months of undifferentiated work into an integration and review task, letting the team spend its first weeks on the thing customers actually pay for. The case against it is dependency risk: it is a small, single-maintainer project on bleeding-edge versions, with no support contract, so we would own upgrades and security review ourselves. Recommendation: fund a two-week spike, not a platform commitment. Success criteria are explicit — auth, teams, and an admin screen running in staging, one upgrade path exercised, and a written list of what we'd own. If the spike clears, adopt with a named owner and a quarterly upgrade budget; if not, we've spent two weeks to avoid a year of drag.

For engineering — the short version: You get Laravel 13 / PHP 8.5 with Filament 5 + Livewire 4 for admin and internal tooling, Jetstream for auth/teams/2FA/API tokens, and Sociallite for OAuth providers. The repo also ships agent-oriented tooling: an AGENTS.md describing a Podman-based local environment (lerd) with a grouped MCP server, framework-agnostic service and database management, git worktrees that get their own <branch>.<site>.test subdomain, and per-branch env seeding. Treat that as the highest-value and least-proven part — it's a genuine productivity multiplier for parallel work and code review, but it also means your dev environment contract is now someone else's YAML.

What we own on day one: the fork, the upgrade cadence against four fast-moving majors, a secrets/auth review against our own threat model, and a decision on multi-tenant isolation. What we're explicitly not buying: support, roadmap influence, or a security attestation. Budget accordingly and assign an owner before the first commit.