Laravel Starter Kit Inertia Vue Laravel Package

Technical Evaluation

Architecture fit. This is not a library — it is an opinionated application scaffold (Laravel 13 + Inertia v3 + Vue, Fortify auth, Wayfinder, Pest, Larastan, Pint, Rector, Boost/MCP). It is consumed by scaffolding (laravel new / composer create-project / clone-and-fork), not by composer require. The 0 dependents figure is therefore an artifact of the distribution model rather than a quality signal, but it does mean there is no downstream ecosystem validating upgrade paths. Fit is high for greenfield Laravel products and essentially zero for retrofitting an existing application.

Integration feasibility. The kit encodes a coherent set of conventions we would otherwise have to debate: an Action pattern in app/Actions with a single handle(), constructor injection, DB::transaction() around multi-model writes, declare(strict_types=1), final readonly classes, and enforced test coverage per change. It also ships AI-agent operating instructions (AGENTS.md, Laravel Boost guidelines, skill activation rules) — valuable if the team uses Boost/MCP tooling, dead weight otherwise. Adopting it is a day-zero decision, cheap to execute, expensive to reverse.

Technical risk. The version matrix is aggressively forward-looking: PHP 8.5, Laravel 13, Inertia v3, Pest v5, and three pre-1.0 dependencies (Wayfinder v0, MCP v0, Prompts v0). Inertia v3 is itself a breaking surface — Axios removed, Inertia::lazy() removed in favour of optional(), event renames (invalid→httpException, exception→networkError), router.cancel()→router.cancelAll(). Hosting and CI images may lag on PHP 8.5. As a fork, there is no semantic-versioning contract and no upstream merge guarantee, so every future upgrade is a manual reconciliation.

Key questions.

• Is Vue + Inertia our committed frontend stack, and does the team have Inertia v3 experience (not v1/v2)?
• Can our hosting, CI, and container base images support PHP 8.5 and Laravel 13 today, or is that a 6–12 month bet?
• Do we want Fortify as the auth backend, or does our identity model require SSO/Socialite/Passport — which this kit does not cover?
• Who owns the fork, and what is the cadence for cherry-picking upstream changes versus accepting permanent divergence?
• Are we buying into the Action-pattern mandate as a house standard, or will it fragment once teams customize?
• With 84 stars and low opportunity scoring, is single-maintainer abandonment an acceptable risk for a foundation layer?

Integration Approach

Stack fit. Suitable only for greenfield or near-greenfield services. For existing Laravel applications, treat the kit as a reference architecture — port the Action convention, Fortify configuration, and Wayfinder setup selectively rather than introducing a parallel structure.

Migration path. Two viable tracks:

1. Greenfield fork-and-own — scaffold from the kit, immediately re-point origin to our repo, add the upstream as a read-only remote, and treat the initial commit as our baseline. This is the intended path.
2. Pattern extraction — for existing apps, lift specific conventions (Actions, strict types, Pest, Pint, Larastan, Rector) incrementally with a lint/CI gate, skipping the Inertia/Vue scaffold entirely if the frontend is already established.

Compatibility. Hard prerequisites: PHP 8.5 runtime, Node/Vite build toolchain, and a matching @inertiajs/vue3 client version. Wayfinder introduces a codegen step (wayfinder:generate) that frontend route imports depend on — it must be part of the build pipeline, not a developer's local ritual. Rector and Larastan versions are pinned to the Laravel 13 era; mixing with an existing codebase on older Laravel will produce false positives.

Sequencing.

1. Pin and lock the full dependency matrix in the fork; record the upstream commit SHA as the baseline.
2. Establish fork ownership, upstream remote, and a documented cherry-pick policy before feature work begins.
3. Wire CI to the shipped quality gates (Pest, Pint, Larastan, Rector) and confirm they pass on the untouched scaffold.
4. Validate PHP 8.5 in staging and production images — this is the gating infrastructure risk.
5. Customize Fortify (registration, 2FA, verification, throttling) to our auth requirements.
6. Integrate Wayfinder codegen into npm run build / CI so route drift fails fast.
7. Begin domain work in app/Actions, enforcing the one-handle() convention in code review.
8. Prune or rewrite the AGENTS.md / Boost skill files to match our actual conventions before teams rely on them.

Operational Impact

Maintenance. The dominant cost is fork stewardship. There is no upstream merge path and no release contract; upgrades are manual diffs against a moving template. Budget recurring engineering time for upstream reconciliation, or accept deliberate drift and document it. The pre-1.0 dependencies (Wayfinder, MCP, Prompts) will ship breaking changes in minor releases — pin them exactly and upgrade on our schedule, not theirs.

Support. Community OSS with a small maintainer surface and modest adoption. There is no vendor SLA, no security advisory process we can depend on, and effectively single-maintainer bus-factor risk. Our fork must be treated as internally owned from day one; upstream is a convenience, not a support channel.

Scaling. Application scaling is standard Laravel territory — queue workers, cache, DB, and horizontal app servers, none of which the kit constrains. Two kit-specific considerations: Wayfinder adds build-time codegen that grows with route count and must stay deterministic across environments; Inertia SSR is simplified via @inertiajs/vite but remains an optional operational surface — decide explicitly whether we run SSR or client-only, because the Node runtime implication differs.

Failure modes.

• Vite manifest errors (Unable to locate file in Vite manifest) on deploys where npm run build was skipped — a recurring class of incident in Inertia deployments.
• Wayfinder drift — stale generated route helpers after a controller rename; fails at build or, worse, produces dead links.
• Environment skew — CI on PHP 8.4 while production runs 8.5 (or vice versa), surfacing as hard-to-diagnose type or deprecation failures.
• Inertia v3 migration debt — engineers applying v1/v2 idioms from existing knowledge (Axios, lazy(), old event names) produce silently wrong behaviour rather than errors.
• Stale agent guidance — if AGENTS.md and Boost skill files drift from our real conventions, AI tooling will confidently generate non-conforming code.
• Auth surface — Fortify is powerful but configuration-heavy; a misconfigured throttle or verification flow is a security-relevant defect, not a cosmetic one.

Ramp-up. The Action pattern and strict-typing conventions are a half-day of onboarding. Fortify is the steepest curve (multi-day for someone new to it). Wayfinder is new to nearly everyone and needs a short internal write-up. Inertia v3 plus Vue requires existing SPA competence; do not staff this with a Blade-only team and expect velocity in week one. The Boost/MCP and agent-skill layer is a genuine productivity multiplier for teams already using Laravel Boost, and pure noise for teams that are not — make that adoption decision explicitly rather than inheriting it from the scaffold.