Laravel Laravel Package

Product Decisions This Supports

• Stack standardization (build vs. assemble): This is a starter skeleton, not a runtime library — adopting it is a one-time scaffold decision, not a permanent dependency. That makes it a low-risk way to standardize a team on Laravel 12 + Inertia v2 + React 19 + Tailwind v4 + TypeScript route generation (Wayfinder) without writing and maintaining your own boilerplate. As of v2.0.5 the frontend also ships a pre-selected component layer (Intent UI v4) and a single toolchain (Vite+) for build, lint, and format — narrowing the "assemble it yourself" surface even further.
• Design system decision (buy vs. build vs. adopt): The skeleton now hard-wires Intent UI v4 as the component library. That converts "which UI kit, and do we build our own?" from a per-project debate into a default. Product-relevant upside: Intent UI is built on React Aria, so accessibility behavior (focus management, keyboard interaction, ARIA semantics) arrives with the components rather than becoming a per-sprint backlog item — valuable if you sell into procurement-gated or public-sector buyers. Downside to weigh explicitly: your visual identity and component extension path now start from Intent UI's opinions, and swapping it out later is a frontend refactor, not a config change.
• Toolchain consolidation / platform-ops overhead: Replacing Biome plus the separate Vite/ESLint/Prettier plumbing with Vite+ means one tool to install, configure, cache, and upgrade across every project. For a PM this is mostly a hidden-cost decision: fewer moving parts in CI and fewer "works locally, fails in pipeline" incidents, at the cost of betting on a newer, less-battle-tested unified toolchain.
• Time-to-first-feature roadmap planning: The default answer on "when does the team ship something user-visible?" changes because auth (Sanctum), routing conventions, testing (Pest 3), PHP formatting (Pint), local dev (Sail), frontend bundling, and now a component library with accessible primitives are pre-wired. Roadmaps can compress the "setup sprint" out of the first milestone — and the UI-kit default removes an additional design/dev alignment cycle before the first screen ships.
• AI-assisted development strategy: The bundled AGENTS.md / Laravel Boost guidelines remain the most product-relevant differentiator. They encode conventions (Form Requests over inline validation, Model::query() over DB::, eager loading to avoid N+1, PHPDoc over inline comments, mandatory tests per change) directly into the agent context. This supports a decision to invest in agentic tooling (Cursor, Claude Code, Boost MCP) as a productivity lever rather than an experiment. Note that v2.0.5 changed the frontend toolchain, so any agent instructions referencing Biome or the old build commands should be re-validated before teams rely on them.
• Quality-gate policy: "Every change must be programmatically tested" is codified in the skeleton. That's a policy decision you can point to when justifying test-coverage requirements or CI gating to engineering leadership. Lint/format gating now runs through a single Vite+ entry point, which simplifies the CI story you describe to leadership.
• Hiring and onboarding decisions: A canonical skeleton shrinks the "where does this go?" surface area, which changes onboarding cost estimates and lowers the bar for mid-level hires joining an unfamiliar codebase. A named component library also gives new frontend hires a concrete reference point instead of bespoke patterns.
• Architecture debates to close out: Inertia-vs-Livewire-vs-API-only, Blade-vs-React, Tailwind-vs-CSS-modules, and now component-library-vs-bespoke-UI are effectively pre-decided here. Treat adoption as a decision to stop re-litigating those per project.
• Use cases well served: internal tools and admin dashboards, SaaS MVPs, authenticated CRUD apps, anything where a server-driven SPA (Inertia) gives you SPA UX without SPA operational overhead — and where an accessible, opinionated component kit is a feature rather than a constraint.
• Dependency and governance decisions: 163 stars and 0 dependents on a skeleton is expected, not alarming — but it does mean you are betting on a small downstream of laravel/laravel rather than the upstream project itself. v2.0.5 reinforces this: a patch-level release migrated a major component library version and swapped the entire frontend toolchain. That is a legitimate velocity signal but also a churn signal — budget a decision on whether to track this skeleton or the official one, and pin versions deliberately.

When to Consider This Package

Adopt when:

• You are starting a greenfield PHP app and have already chosen Laravel. This delivers value only at create-project time.
• The team is comfortable with React and TypeScript and wants Inertia's server-driven SPA model rather than a fully decoupled frontend.
• You are happy to inherit Intent UI v4 as the component library, or at least willing to evaluate it against your brand and design requirements before committing. If accessibility compliance is on your roadmap, this is a net positive.
• You can run PHP 8.4 and Laravel 12 in dev and CI — the pinned ecosystem (Inertia v2, Wayfinder v0, Boost v2, MCP v0, Intent UI v4, Vite+) is version-specific and the docs guidelines assume exactly these.
• You are actively deploying AI coding agents on the repo. Without that, the AGENTS.md/Boost content is inert documentation and roughly half the differentiation disappears.
• You want opinionated conventions enforced from day one: Form Requests, named routes, queued jobs, API Resources + versioning, factories and seeders created alongside models.
• You want one frontend toolchain and are willing to adopt Vite+ for build, lint, and format instead of maintaining separate Biome/ESLint/Prettier configuration.

Look elsewhere when:

• You are on an existing Laravel app. This is a skeleton; retrofitting it means a migration, not an install. Teams already on Biome, ESLint, or a hand-rolled Vite config face an unplanned toolchain migration on top of that.
• You want Livewire/Alpine or a Blade-only stack — this skeleton hard-codes Inertia + React and will fight you.
• You already have a design system or component library commitment (shadcn/ui, MUI, an in-house kit). Intent UI v4 is now part of the scaffold; overriding it means fighting the skeleton rather than benefiting from it.
• You need a headless/API-only backend for mobile or third-party clients. Sanctum is present, but the Inertia/React/Tailwind/Wayfinder/Intent UI half becomes dead weight.
• You require LTS guarantees, vendor support SLAs, or a published security-response process. A 163-star downstream skeleton does not provide that; evaluate official laravel/laravel or a commercially supported starter.
• Your org forbids v0/pre-1.0 dependencies. Wayfinder, Boost, MCP, and Prompts are all pre-1.0 here, and Vite+ is a young unified toolchain — treat it as the newest risk in the stack, particularly if your CI depends on mature, widely-documented build tooling.
• You need a documented upgrade path. Merging upstream skeleton changes into an app you've already customized is manual work; v2.0.5 (component library major migration + toolchain swap in a patch release) is a concrete example of that drift landing on you mid-project. If skeleton drift is a real concern, minimize divergence from upstream and treat this as a fork you now own.
• Your team lacks React/TypeScript depth — Inertia lowers the SPA tax but does not remove the frontend skill requirement.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a pre-assembled starting point for Laravel applications, not a piece of vendor software we'd depend on at runtime. Adopting it means a new product starts with authentication, testing, code formatting, local environment, the full frontend build pipeline, and now a component library with built-in accessibility already configured and standardized — we skip the setup phase and go straight to features. The newest release tightens this further: it consolidates the frontend build, lint, and format steps into a single tool and standardizes the UI components, which reduces moving parts and shortens the path to a first shippable screen. Because it's a template we copy once and then own outright, there is no lock-in and no ongoing licensing cost; the real commitment is to a specific, current technology stack (PHP 8.4, Laravel 12, React 19, Intent UI), which we should confirm aligns with our hiring, hosting, and brand/design plans. The notable extra is that it ships with written conventions designed for AI coding assistants, which is where most of the potential productivity gain sits — and it's worth a measured pilot rather than a mandate.

For engineering leadership: The value is conventions, not code volume. It removes per-project arguments about validation placement, query style, route references from the frontend, component library choice, and test expectations, and it encodes those rules into a format AI agents actually consume. v2.0.5 changed two things worth flagging: the frontend component layer is now Intent UI v4 (React Aria-based, so accessibility behavior comes for free but is a harder dependency to reverse), and Biome plus the surrounding JS tooling was replaced by Vite+ for build, lint, and format (one tool, fewer configs, but a newer and less-proven piece of the stack). Two caveats to state plainly: the project is small (163 stars, zero dependents) so we are effectively adopting a downstream of the official Laravel skeleton and should track upstream ourselves — and the fact that a patch release carried a component-library major migration and a full toolchain swap tells you to pin versions and read changelogs before bumping. Recommended path: run one real, non-critical project through it end-to-end, measure setup time and the rate of convention drift, validate that the AI agent guidelines reflect the new toolchain, and only then make it the default.