Slate Laravel Package

Product Decisions This Supports

• Build vs. buy for the front-end layer. Slate answers a recurring question: do we rebuild a component library in-house, adopt a paid kit (Flux, Filament), or move to Inertia + shadcn? Slate is the "keep Blade, get the shadcn look" option — a credible third path that avoids a React/Vue re-platform just to get a modern UI.
• Stack standardization: Blade + Livewire vs. SPA. Because it's anonymous Blade components, Tailwind v4, and Livewire-ready, adopting it is effectively a vote to stay on server-rendered Laravel. That's a roadmap-level commitment, not just a dependency choice — decide it deliberately.
• MVP scope and time-to-demo. The components + blocks library (marketing sections, dashboard shells) compresses the "make it look real" phase of an internal tool or early product. Useful for sizing how much design/front-end effort a milestone actually needs.
• Design-system ownership. "Slate-owned theme tokens" is the decision that matters most. Adopting means our brand layer sits on top of someone else's token vocabulary. PM call: are we willing to express our design system as an override, or do we need tokens we own? Answer this before the first sprint, not after.
• Tailwind v3 → v4 migration timing. Tailwind v4 is a hard prerequisite. If a v4 upgrade is already on the roadmap, Slate can be the forcing function; if not, this package becomes a dependency on a migration we haven't funded.
• Tech-debt / exit-cost planning. It's a Composer dependency rather than copy-in source (unlike literal shadcn). That means upgrade paths are the maintainer's to define — worth an explicit "can we fork and own this?" line in the risk register.
• AI-assisted development investment. The llms.txt and MCP/agent docs are a genuine differentiator for teams leaning on AI coding tools: machine-readable component contracts reduce hallucinated props and shorten onboarding. Supports a decision about whether to standardize on libraries that ship agent-facing docs.

When to Consider This Package

Consider it when:

• The app is greenfield or early, on Laravel 12/13, with a Blade + Livewire stack and no appetite for Inertia/React.
• You're already on Tailwind v4, or the upgrade is funded and scheduled.
• The team is small and design-literate enough to work from a component catalogue rather than a Figma-driven design system.
• The UI is internal tools, dashboards, admin surfaces, or a marketing site — not a differentiated, brand-critical customer front end.
• You need the shadcn aesthetic on a timeline where building it yourself isn't viable.
• You have engineering capacity to read the source, publish views, and patch locally if needed.

Look elsewhere when:

• You require vendor support, SLAs, or long-term maintenance guarantees — 33 stars, zero dependents, and a single-package maintainer footprint mean you are the safety net.
• You're pinned to Tailwind v3, or your tokens live in a mature tailwind.config.js design system you can't re-platform.
• You need rich stateful components — complex data tables, charts, comboboxes with server state, notification systems. Livewire-ready ≠ Livewire component library; evaluate Flux or Filament for that tier.
• You're on Inertia/React/Vue, where real shadcn (or shadcn-vue/svelte) is strictly better.
• Accessibility certification or compliance is a procurement gate — a young kit won't have the audit trail.
• Your team can't absorb the risk of an under-adopted dependency: no Stack Overflow corpus, no third-party tutorials, thin hiring signal, and bus-factor of roughly one.

How to Pitch It (Stakeholders)

To executives: We can get a modern, shadcn-quality interface without re-platforming the front end or buying a commercial UI licence. It's MIT-licensed, integrates with the Laravel stack we already run, and is designed to let us take ownership of the code if the project stalls. The trade-off is support maturity — this is a young, low-adoption package, so we treat it as a codebase we're adopting, not a vendor we're relying on. Recommendation: pilot on one internal surface, with a documented fork-and-own fallback.

To engineering: Anonymous Blade components mean no per-component PHP class overhead, and views are publishable, so overriding is normal Laravel work rather than fighting an abstraction. It targets Laravel 12/13 and Tailwind v4 with dark mode and Livewire compatibility built in. The exit cost is low by design: worst case we vendor the components into our own namespace and own them. The costs are real too — a Tailwind v4 prerequisite, a token layer defined by the package, and a tiny upstream community, so we should budget a day to read the source before committing and pin versions deliberately.