Laravel Starter Kit Inertia React Laravel Package

Technical Evaluation

Architecture fit

• This is a project skeleton, not a consumable library. It is adopted via laravel new / composer create-project, not composer require. There is no runtime artifact to embed in an existing codebase.
• Fit is therefore greenfield-only. For an existing Laravel app, the only realistic use is as a reference architecture (Action pattern, strict typing, Wayfinder route bindings), not an integration.
• Highly opinionated by design: Action classes in app/Actions with a single handle(), no service-layer suffix conventions, declare(strict_types=1) throughout, Pest-only tests, high-level Larastan, Rector in the toolchain. Adopting the kit means adopting a full convention set, not a component.
• Ships agent-facing rules (AGENTS.md, Laravel Boost MCP, per-domain skills for Wayfinder/Fortify/Laravel best practices). This is the differentiating capability: it is an AI-assisted-development baseline as much as a code baseline.

Integration feasibility

• Zero dependents is expected and not a red flag — starter kits are never depended upon. It also means no downstream validation signal: we cannot point to third-party production usage.
• No upgrade contract. Once forked, upstream improvements are manual cherry-picks; divergence is one-way.
• Multi-toolchain surface: Composer (PHP 8.5), npm/Vite, Node-side Wayfinder codegen, optional MCP server. Each is an additional CI and onboarding dependency.

Technical risk

• Bleeding-edge version matrix: PHP 8.5, Laravel 13, Inertia v3, Pest v5, PHPUnit 13, Larastan v3, Rector v2, plus pre-1.0 laravel/wayfinder (v0) and laravel/mcp (v0). Pre-1.0 packages have no stability guarantee and can break on minor bumps.
• Runtime availability risk: PHP 8.5 may not be offered by our host/PaaS or base images yet; Laravel 13 constrains the third-party package ecosystem we can add.
• Strictness tax: ultra-strict static analysis and typing will fail CI on pasted/legacy code, increasing short-term delivery friction.
• Knowledge concentration: single maintainer (high individual credibility, low bus factor). 245 stars indicates a small, early audience.

Key questions

1. Is this for a new service or are we trying to retrofit an existing app? (If the latter: stop.)
2. Can our runtime/CI supply PHP 8.5 and Laravel 13 today, and do our must-have packages support them?
3. Is Inertia + React our sanctioned frontend, and do we need SSR (adds a Node runtime)?
4. Who owns the fork, and what is our upstream-sync cadence and budget?
5. Do we want AI agent rules and the Boost/MCP tooling committed to our repos, and does that pass security review?
6. What is the licensing and code-provenance check on the scaffolded code?

Integration Approach

Stack fit

• Baseline stack: Laravel 13 + Inertia v3 + React + TypeScript + Vite, Fortify for auth, Wayfinder for generated typed route functions.
• Requires team fluency in Inertia v3's newer surface (useHttp, optimistic updates, useLayoutProps, instant visits, Inertia::optional()/defer()/merge()) — this is not the Inertia most teams know.
• Best fit where we already run Laravel + React monolith-style SPAs; poor fit for API-first/separate-frontend architectures.

Migration path

• No migration path exists. Treat adoption as project inception, not an upgrade.
• Recommended: create an org-owned internal template repo seeded from a pinned upstream commit, with our additions (CI, deploy, secrets, observability, house conventions) layered on top. Consume that internally, never upstream directly.
• Explicitly decide what to keep vs. strip (Boost/MCP, Wayfinder, agent skills). Note stripping agent skills also removes the kit's main differentiator.

Compatibility

• No semver, no changelog contract, no upgrade guide. Version the snapshot, not the dependency.
• Third-party package additions must be validated against Laravel 13 / PHP 8.5 / Inertia 3 before we commit to the platform.

Sequencing

1. Spike on one low-risk internal service: scaffold, run the full toolchain (Pint, Larastan, Rector, Pest), build, deploy to a staging target.
2. Validate the two hard gates: PHP 8.5 runtime availability, and top-5 required third-party packages on Laravel 13.
3. Internalize: fork into an org template repo; document deviations and an upstream-sync runbook.
4. Pilot a second team on the template to confirm the ramp-up estimate and convention friction.
5. Decide: standardize, or retain as reference-only. Do not standardize after a single successful spike.

Operational Impact

Maintenance

• We own the fork outright: security patches, dependency bumps, and toolchain upgrades are ours. Upstream may move fast and break conventions between releases.
• No LTS. Budget ongoing maintenance for the strict toolchain itself (Rector/Larastan rule drift causes CI churn independent of product code).
• Single-maintainer upstream: abandonment risk is real; assume the fork must be self-sustaining within two quarters.

Support

• Community-only: GitHub issues, no SLA, no commercial backing. 245 stars implies uncertain response latency and thin Stack Overflow coverage for kit-specific problems.
• Much of the "documentation" is agent-oriented (AGENTS.md, skills). That serves AI-assisted workflows well but is a weak artifact for human onboarding and for architecture review records.

Scaling

• Application scaling is unaffected — standard Laravel, standard horizontal options.
• Build-time scaling: Wayfinder codegen and Vite become required CI steps; SSR (if enabled) adds a Node process to the runtime topology and its own scaling/monitoring story.
• Team scaling: strict typing and Action-pattern discipline raise the entry bar but reduce review ambiguity — a net positive only if we enforce it uniformly.

Failure modes

• Upstream drift/abandonment — forks rot silently; no security backport path.
• Version-lock collisions — Laravel 13 / Inertia 3 constraints block a needed package mid-delivery.
• Wayfinder codegen failure — breaks the TypeScript build; a single point of failure in the pipeline.
• Static-analysis gate creep — Larastan/Rector upgrades fail CI on untouched code, stalling releases.
• Agent-rule drift — committed agent guidelines silently steer generated code toward conventions we haven't ratified; requires governance, not just a README.
• Runtime gap — PHP 8.5 unavailable in prod images discovered late, forcing a downgrade cycle.

Ramp-up

• Laravel-fluent engineers: ~1–2 weeks to productive, dominated by Inertia v3 APIs and Wayfinder, not by Laravel itself.
• Teams relying on AI-assisted development: materially faster, since the kit encodes conventions and skills the agent can activate — this is the strongest argument for adoption.
• Non-Laravel or API-first teams: not a fit; avoid.
• Add ~1 week of platform/tooling setup (PHP 8.5 images, codegen in CI, MCP/Boost governance review) before the first feature ships.

TPM recommendation: treat as a template to fork and own, not a dependency. Proceed only with a greenfield service, a confirmed PHP 8.5 runtime, and a named fork owner; otherwise use it as an architectural reference for Action-pattern and typed-route conventions.