Laravel Nuxt Shadcn Laravel Package

Product Decisions This Supports

• Build vs. buy for project scaffolding: laravel-nuxt-shadcn sits in the "buy" (adopt) column for anything that needs a Laravel API + Nuxt frontend with shadcn-vue components. It removes the multi-day lift of wiring auth, SSR, API client, and a component library—work that adds zero differentiation to your product.
• Time-to-first-prototype / discovery sprints: Because the scaffold produces a runnable full-stack app in one command, it shortens the loop between "we think there's an opportunity here" and "here's a clickable prototype a stakeholder can log into." That directly de-risks roadmap bets before engineering headcount is committed.
• Standardizing the internal stack: Adopting one scaffold as the team's default template is a platform decision, not a tooling preference. It sets conventions for directory layout, API contracts, and UI primitives across every new service, which reduces onboarding cost and cross-team code review friction.
• Roadmap sequencing for a new product line: If the roadmap includes a new customer-facing app in the next two quarters, this package is a candidate for the "phase 0" line item—budget hours, not weeks, for the initial skeleton.
• Release v0.2.2 specifically: The fix ships the app README and resets the package name in generated apps. This is a deliverable-quality fix, not a feature. It matters to the PM because generated repos previously inherited the upstream package's identity—meaning every app your team scaffolded carried a stranger's project name in package.json and no README. That's a small but visible embarrassment in any repo handed to a client, an auditor, or a new hire. Worth noting as evidence the scaffolding templates are still being corrected, which is the kind of churn that shows up as cleanup work in sprint one.

When to Consider This Package

Adopt when most of the following hold:

• Stack fit is exact. Your team is already committed to or explicitly choosing Laravel on the backend and Nuxt (Vue) on the frontend, with shadcn-vue for UI. This package is opinionated; it is not a general-purpose bridge.
• Velocity outweighs control. You're building a new app where conventions are still cheap to set, so inheriting someone else's structure is a net gain rather than a source of friction against an established codebase.
• You can absorb pre-1.0 risk. At v0.2.x, breaking changes are expected and semver gives you no protection. Only adopt if you can pin a version, vendored/forked if needed, and own the upgrade work yourself.
• You need a demo or internal tool, not a regulated production system. The benefit is speed; the cost is dependence on a single maintainer with no commercial support, security policy, or release cadence you can contract for.
• You're evaluating a template, not a runtime dependency. If you scaffold once and then own the code, the maintenance risk is time-boxed. If the package stays in the dependency graph of a long-lived product, risk compounds.

Look elsewhere when:

• You need Inertia + Vue, Livewire, or Nuxt UI rather than a Nuxt-first SPA/SSR frontend—those are better served by Laravel's official starter kits.
• You require vendor support, SLAs, or a security disclosure process.
• The app is long-lived and mission-critical, and your team lacks the capacity to fork and maintain the scaffold.
• Your organization has an existing, enforced frontend standard that this package would contradict.

How to Pitch It (Stakeholders)

For executives: This is a project starter kit—it does for a new web app roughly what a document template does for a contract. Instead of spending the first one to two weeks of a project on plumbing (login, database, API wiring, UI components), the team starts from a working application on day one. The decision to make is not "is this good software" but "do we want to standardize on this stack and accept that the kit is early-stage." The risk is contained: we scaffold once and own the resulting code, so the worst case is some manual cleanup rather than a lasting dependency.

For engineering: The v0.2.2 release is a small correctness fix—generated apps now carry their own package name and ship a README, so scaffolded repos no longer inherit upstream metadata. That is the good news and the caveat: at v0.2.x the templates are still being patched, so budget a short hardening pass on anything scaffolded. Recommend we pin to an exact version, review the generated output rather than trusting it, and treat the scaffold as a starting point we fork and own—not a dependency we track. If the team's frontend direction is Inertia or Livewire, this isn't the right tool and we should say so now.