Laravel Starter Kit Laravel Package

Product Decisions This Supports

• Build vs. buy for greenfield delivery: This is a scaffold, not a runtime dependency — adopting it is a "buy the starting line, own the code" decision. It replaces the 1–4 weeks of setup (auth, layout, UI primitives, CI) that otherwise precedes the first user-facing feature on every new Laravel/Vue product.
• Standardizing the stack across teams: The kit encodes opinionated conventions (Laravel + Inertia + Vue + shadcn-vue-style UI, vue-sonner toasts). Choosing it is effectively ratifying a house stack — a decision that compounds across hiring, code review, and shared component reuse.
• Upstream maintenance strategy (roadmap-relevant): The new .starter-kit.json version stamp plus the CLI install/update docs (PRs #34, #39) signal a supported upgrade path. This is the deciding factor for roadmap planning: it determines whether we can inherit upstream fixes cheaply or are committing to fork-and-drift.
• Scope of generated projects: PR #36 excludes starter-kit-only files from new projects, so output is a lean app rather than a repo full of maintainer tooling. Reduces onboarding noise and the "what is all this?" tax on new hires.
• Release hygiene as a proxy for vendor risk: Automated release workflow, scoped write permissions on the release job (#34, #38), and grouped Dependabot updates (#33, #35) indicate the project is being run with production discipline — relevant when deciding whether to depend on it for multiple products.
• Spike/MVP throughput: For discovery work and internal tools, the kit's value is compressed time-to-demo; it lets a PM commit to a prototype date without a platform-team dependency.

When to Consider This Package

Adopt when:

• You are starting a new Laravel application with a Vue/Inertia front end (or are willing to standardize on one).
• You expect to spin up multiple similar products or internal tools where consistent conventions beat per-project bespoke setup.
• Your team will actually use the included scaffolding — auth flows, layout, UI primitives, toast/notification patterns — rather than ripping it out.
• You value a repeatable update path: the CLI + version-stamp mechanism makes it reasonable to pull upstream fixes into generated projects on a cadence.
• The maintainer's release cadence and stack choices match your own dependency policy — this release is a good sample: docs, CI hardening, dependency bumps, one UI bugfix. No breaking changes, low upgrade cost.

Look elsewhere when:

• The application already exists. Starter kits are copy-once scaffolds; retrofitting means manually porting conventions, and the update CLI assumes a lineage your codebase doesn't have.
• You need a composer-installable library with semantic versioning guarantees rather than a template you fork. Upgrades here are effectively merges, not composer update.
• Your stack is Livewire, React, or API-only — the kit's value is concentrated in its Vue/Inertia front end.
• You require vendor support contracts, SLAs, or a multi-maintainer bus-factor guarantee. Release history shows a single primary maintainer; assess that risk explicitly.
• Long-lived, heavily customized products where divergence will make upstream updates net-negative within a quarter.

How to Pitch It (Stakeholders)

For executives: This is a pre-built starting point for new Laravel web applications — the equivalent of a fitted-out kitchen rather than an empty room. It removes roughly the first two to four weeks of setup on every new product (login, permissions, layout, notifications, deployment pipeline) and standardizes how our apps look and behave, which lowers onboarding cost and makes engineers interchangeable across projects. The latest release is maintenance-grade: documentation for the install/update CLI, tightened release security, dependency refreshes, and one notification-styling fix — no breaking changes, no migration work. The strategic point is the update mechanism: new projects carry a version stamp and can pull in upstream fixes, so this is a maintained foundation rather than a one-time copy. Principal risk is concentration — a small maintainer team — which we mitigate because we own the generated code outright and can maintain it ourselves if needed.

For engineering: v1.4.1 → v1.4.4 is a low-risk bump. Highlights: the CLI can now install into a new project and update an existing one, with the version recorded in .starter-kit.json (PRs #34, #39); starter-kit-only files are excluded from generated projects, so scaffolds start clean (#36); the vue-sonner stylesheet is now imported so toast notifications render correctly (#37); release workflow permissions are scoped to the release job (#38). Dependency and CI updates are routine.

Recommended next step: pilot the kit on one non-critical internal project, time-box the first feature to measure the actual setup savings, and validate the CLI update path against a deliberately customized project before we standardize on it across the roadmap.