Blatui Laravel Package

Product Decisions This Supports

• Build vs. buy for internal/admin UI. This is a direct, no-cost substitute for a paid component suite (Flux Pro being the explicit comparison in the README). If a licensing renewal is on the roadmap, this package is the alternative that removes a recurring line item rather than renegotiating it.
• Feature delivery velocity on Laravel surfaces. 155 components / 614 variants / 64 blocks in Blade means settings pages, CRUD forms, auth flows, and dashboards move from design-ticket to shipped in days. This is the strongest argument for a PM: it compresses the highest-volume, lowest-differentiation work.
• Design-system ownership strategy. The copy-in model makes the UI layer a fork you own, not a dependency you consume. That is a genuine product decision — choose it if you intend to diverge from the design language (brand theming is a first-class oklch/CSS-variable layer), avoid it if you want centrally versioned upgrades with a support contract.
• Accessibility/compliance roadmap. WCAG AA + axe-core auditing ships in the components. This lets you answer enterprise procurement accessibility questionnaires without opening a separate remediation epic — often a quarter of engineering time.
• Stack consolidation. If Laravel is the backend and the frontend is a React/Vue island, this eliminates the island: one language, one build pipeline, one hiring profile. That is a headcount and onboarding decision, not just a UI decision.
• Analytics/dashboard roadmap items. 70 ApexCharts-backed charts plus full-page blocks cover the "we need an admin dashboard by Q3" ask without a bespoke charting build.
• AI-assisted engineering throughput. The bundled blatui:mcp server and skill file let coding agents search and install components correctly — supports any initiative framed as "raise output per engineer."
• Livewire dependency retirement. Full two-way binding on every form control is the specific capability that makes Flux Pro removable. This is the decision to bring to a renewal review.

When to Consider This Package

Adopt when:

• Laravel 11/12/13, PHP 8.2+, Alpine 3, and — non-negotiable — Tailwind v4 already in place or a migration you've already scheduled. On v3 this is blocked, not deferred.
• The frontend is Blade-first and Livewire is in use or planned. Without Livewire, you lose the strongest differentiator.
• Someone on the team will actually own the copied component files. The copy-in model is a maintenance commitment disguised as an install.
• The target surfaces are internal tools, admin panels, dashboards, auth, and marketing pages — not a bespoke public brand experience.
• You want accessibility coverage without hiring for it.

Look elsewhere when:

• Tailwind v3 with no migration appetite, or a heavily customized Tailwind config — the v4-only @theme inline/oklch foundation is a hard gate.
• Inertia/React/Vue frontend — go straight to shadcn/ui; the entire value here is the Blade port.
• You need vendor support or an SLA. 262 stars, 0 dependents, a single maintainer, and a low opportunity score make this an early bet, not a safe default.
• License is unresolved. GitHub reports NOASSERTION while the README claims MIT. Get legal sign-off before this lands in a commercial product — do not wave this through on the README alone.
• You want managed upgrades. blatui:update prompts file-by-file because it cannot distinguish your customization from an outdated copy. Across 100+ installed components that becomes real recurring work. Formatters (Pint/Prettier) create phantom diffs; --ignore-whitespace mitigates but doesn't eliminate this.
• You're already deep on Flux Pro or Filament. Budget for the Alpine bootstrap conflict (the documented duplicate-Alpine trap and registerBlatUI(..., { darkMode: false }) dark-mode handoff) — switching cost likely exceeds the gain.
• You need blocks and charts versioned and vendored. They are copy-paste or fetched from a JSON registry over the network — an external availability and supply-chain dependency your infra team will and should challenge.
• A design language materially different from shadcn's. You will be rewriting the token layer anyway, which erases much of the head start.

Adoption gate I'd set: pin the version, pilot a single settings page or admin CRUD flow, wire blatui:init and blatui:doctor into CI, and only then expand. Treat it as reversible.

How to Pitch It (Stakeholders)

To executives: "An MIT-licensed component library built for the Laravel stack we already run. 155 accessible, production-ready UI components that we copy into our own codebase and own permanently. It removes a paid UI dependency at renewal, cuts the build time on admin panels and dashboards — our highest-volume, least-differentiating work — and ships WCAG AA accessibility that we'd otherwise have to fund as a separate remediation project. There is no lock-in: the worst case is we keep the code we already have on disk."

To engineering: "shadcn/ui ported to Blade + Alpine + Tailwind v4. A CLI copies component source into resources/views/components/ui/ — no runtime package in vendor/, no build-step change, no new framework. wire:model binds on every form control, including date pickers and file uploads. Operational tooling comes with it: blatui:init verifies wiring, blatui:doctor lints Blade footguns (typeless buttons in forms, leaked tags), blatui:update shows a diff before touching anything and backs up what it replaces, and an MCP server lets our AI editors install components correctly instead of guessing."

Honest caveat to state in the same breath: this is a young, single-maintainer project with essentially no downstream dependents, an unresolved license flag, and a copy-in model that makes us the maintainers of record. Recommend it as a scoped, pinned pilot with a thin internal convention over x-ui.* — not a platform-wide commitment — and revisit the decision once we've shipped one real feature on it.