Laravel Starter Kit Vue Laravel Package

Product Decisions This Supports

• Build vs. buy for a new Laravel + Vue SPA. The starter kit encodes an opinionated baseline (Laravel backend, Vue 3 front end, Inertia-style page routing, auth scaffolding, UI component layer including vue-sonner toasts). Choosing it converts "assemble and wire a foundation" from a 2–4 week roadmap item into a half-day bootstrap — the PM decision is whether your team's conventions match its conventions.
• Time-to-first-demo / time-to-first-customer. The most defensible PM framing is cycle time on greenfield products: use the kit to get to a working authenticated shell in days, then spend the saved weeks on the differentiators that actually appear on the roadmap.
• Maintenance model on the roadmap, not just launch. v1.4.6 introduces a CLI-based install and update path plus a .starter-kit.json version marker. That changes the strategic question from "one-time scaffold" to "a scaffold we can re-sync with upstream" — a real input into ongoing engineering-cost estimates and tech-debt planning.
• Supply-chain and release-hygiene policy. The inclusion of a dependency-vetting step that holds back releases for two days, scoped CI release permissions, and Dependabot grouping are governance signals. If your organization has SLSA/supply-chain or dependency-review requirements, this is evidence the upstream takes it seriously — useful when justifying adoption to a security reviewer.
• Upgrade-path planning. A recorded .starter-kit.json version plus documented update CLI means release cadence becomes a recurring roadmap line item ("budget N hours per quarter to re-sync the scaffold") rather than a silent, unbudgeted fork divergence.
• Feature triage aid. The starter-kit-only file exclusions clarify what is yours versus theirs; that boundary map is directly useful when estimating how much of the scaffold you will end up rewriting, and therefore how much of the kit's value you actually retain.

When to Consider This Package

Consider it when:

• You are starting a new Laravel application with a Vue 3 front end and want an opinionated, working baseline rather than a blank laravel new.
• Your team is small-to-mid and would rather adopt a coherent convention set than debate folder structure, auth scaffolding, and UI primitives for two sprints.
• You accept a fork-and-own model: after install the code is yours, and you are comfortable reviewing upstream diffs rather than consuming the kit as a versioned dependency.
• You value an install/update CLI and a version marker — i.e., you intend to track upstream occasionally instead of drifting permanently.
• Your security posture rewards upstream hygiene (scoped CI permissions, dependency vetting with a delay window) rather than requiring vendor-grade SLAs.

Look elsewhere when:

• You need a supported product with an SLA, deprecation policy, or LTS commitment. This is a community starter kit with a release cadence driven by a very small maintainer group; treat it as a template, not a platform.
• You are on a non-Vue front end (React, Livewire, Blade-only, Svelte) or a non-Inertia architecture — the kit's value is tightly coupled to its front-end choices.
• You need long-lived, multi-team upgrade guarantees. The update CLI is recent and evolving; the release notes in this very version are dominated by CI, docs, and dependency chores, which signals a young toolchain rather than a stabilized one.
• Your product is a brownfield app. Retro-fitting a starter kit's conventions into an existing codebase rarely pays back.
• You require vendor accountability for security disclosures or CVE response timelines — the two-day dependency holdback is a good practice, not a contractual guarantee.

How to Pitch It (Stakeholders)

One-liner for executives: A maintained Laravel + Vue starting point that lets a small team stand up a production-shaped application shell — auth, routing, UI components, tooling — in days instead of weeks, with a documented path to pick up upstream fixes later.

Why now (v1.4.6 signals): The release is deliberately unexciting, and that is the point. It ships documentation for the install/update CLI, records the kit version in .starter-kit.json, excludes starter-kit-only files from generated projects, adds a CI release workflow with scoped write permissions, fixes a missing stylesheet import in the Vue toast layer, and introduces dependency vetting that holds upstream packages back for two days before adoption. Read together, these indicate the project is investing in repeatable installation, clean project output, and supply-chain discipline rather than only in features — the traits that matter when you decide to depend on something for a year.

The honest caveats to state up front:

• It is a starter kit, not a framework. Value is realized at project start; the cost is a one-time review of conventions and a recurring, modest re-sync effort each quarter.
• Bus factor is low. A single primary maintainer and a small org mean we should pin to a reviewed commit, keep our own fork, and never assume upstream will prioritize our issues.
• No breaking changes or deprecations in this release. v1.4.1 → v1.4.6 is dependency, CI, docs, and a one-line style-import fix — safe to adopt, and safe to ignore if we are already on the kit.

What we are asking for: Approval to use the kit as the baseline for the next greenfield service, with a two-day review gate on the generated diff before merge, and a standing ~half-day-per-quarter allowance for re-syncing against upstream releases. Success measure: time from repo creation to a deployed, authenticated, test-covered shell — target under one week.