Laravel Ui Kit Laravel Package

Product Decisions This Supports

• Build vs. buy for commodity surfaces. Auth (login, register, reset, verification), an admin shell, a users CRUD, and profile/2FA are non-differentiating for almost every product. This package lets you buy that time back and spend engineering on the thing customers actually pay for.
• Time-to-first-admin as a roadmap lever. Installer claims ~2 minutes to a working auth + admin UI on a fresh Laravel app. That compresses "we can't demo the back office until sprint 3" into a day-one capability, which directly affects when you can put a prototype in front of design partners or internal ops.
• Feature sequencing via the module picker. The 9 optional modules (permissions, support tickets, changelog, contacts, analytics, profile/2FA, impersonation, activity log, dark mode) map cleanly onto a backlog. You can ship core auth + admin in week 1 and defer admin-middleware, impersonation, and activity-log until you have real users and real support load — avoiding premature Spatie Permission complexity.
• Stack standardization. Committing to Livewire 3 + Volt + Fortify + Tailwind 3 is a durable architectural decision. This package effectively pre-commits you to it; treat adoption as endorsing that stack for the admin surface, not just for auth.
• Support/ops tooling as a product decision. impersonation (reproduce user bugs), activity-log (audit trail for compliance conversations), and support-tickets change what your support team can do without engineering. That's a customer-success capability decision, not a code decision.
• Governance on framework support. The README itself flags Laravel 10 as past its security window while still supporting it. If you adopt, set an explicit internal policy: new projects on L11+, and a named owner for version upgrades.
• Brand/system decisions. The Tailwind preset (fonts, palette, dark mode) is opinionated. Decide up front whether you're adopting it or overriding it — otherwise you inherit a design system by accident.

When to Consider This Package

Consider it when all of these hold:

• Greenfield or auth-less codebase — a fresh laravel new project, or an API-only app you're now bolting an admin panel onto. The README is explicit that it's designed for fresh installs.
• No existing starter kit. It collides with Breeze on routes/auth.php, LoginForm.php, and resources/views/livewire/pages/auth/*. It aborts outright on Jetstream. If your app already has either, the install path is "rip out the starter by hand first," which is a separate, riskier project.
• Admin panel is internal-facing or early-stage. Ops consoles, internal tools, MVP dashboards, back-office for a small SaaS. Not a customer-facing product surface where the UI is the differentiator.
• You accept ownership of the generated code. This is a scaffolder, not a runtime library — it publishes Blade views, Livewire components, routes, and a UiKitUser trait into your repo. You will read, review, and maintain them. That's fine, but it must be a conscious yes.
• Small team without a frontend specialist, or a team that has deliberately chosen the TALL stack.
• Time-boxed bet tolerance. With 0 stars, 0 dependents, and no tagged release described, you're adopting an unproven artifact. It's viable as a starting point you fork, not as a dependency you trust to be maintained.

Look elsewhere when:

• You need a mature, supported admin framework. Filament is the default answer for Laravel admin panels with a real ecosystem, plugin surface, and security responsiveness. Nova is the paid equivalent. If admin CRUD is a large share of your roadmap, buy one of those instead of a scaffold.
• You need first-class auth customization — custom Fortify actions, social auth, complex MFA policy. The kit's value is that it isn't customized; customizing it puts you back at square one with extra files.
• Your app needs multi-tenancy, complex RBAC, or API-token/Sanctum-heavy auth. Jetstream's footprint is "heavy" because those needs are heavy. This kit doesn't understand them.
• Compliance or procurement requires vendor due diligence — SLAs, security disclosure policy, release cadence, CVE response. A 0-star, single-maintainer package with no tagged releases won't clear review, and shouldn't be asked to.
• You're on Laravel 9 or earlier, PHP <8.1, Livewire 2, or a non-Vite asset pipeline.
• You need SPA/mobile clients first. Livewire + Blade is server-rendered; a JSON API and a separate frontend is a different architecture.

How to Pitch It (Stakeholders)

To executives: This is a $0-license (MIT) starting kit that removes roughly one to three weeks of undifferentiated work — login, password reset, email verification, an admin layout, a users screen, and optional support/audit/analytics modules — from a Laravel project. It doesn't add a runtime dependency or a subscription; it generates code into our repo that we own outright. The trade-off is that it's new and unproven (no adoption yet, no tagged release), so the recommendation is a one-day spike on a throwaway branch, not a commitment. Success criteria: we get a working /login and /admin in an afternoon and a clear read on how much of the generated code we'd have to rewrite.

To engineering: It's a scaffolder, not a library. php artisan ui-kit:install publishes configs, Blade views, Livewire/Volt components, routes, and a UiKitUser trait into our app, patches config/fortify.php and config/admin.php between idempotent markers, and prints a numbered checklist for the handful of things it won't do (add the trait to User, drop <x-ui-kit::head /> / <x-ui-kit::banners /> into the layout, wire the Tailwind preset and Vite imports). Stack is Livewire 3 + Volt + Fortify + Tailwind 3 on PHP 8.1–8.4, Laravel 10–13, CI-tested across that matrix. Only viable on a fresh app with no Breeze/Jetstream — the installer preflights for those and aborts on Jetstream. Everything it publishes is reviewable diff in our repo, so the exit cost is low: we keep the files, drop the package.

The honest risk slide: 0 stars, 0 dependents, no tagged release, README + CHANGELOG only, single-maintainer profile. Mitigations: pin to a specific commit, review every published file before merging, tag our own baseline so we're not tracking main, and treat it as a fork-on-day-one starting point. Also flag that it supports Laravel 10 despite L10 being out of security support — we should set the internal rule that new projects start at L11+ regardless of what the package tolerates.

The ask: approve a time-boxed evaluation (one engineer, one day, fresh app, --modules=admin-middleware,profile) with a go/no-go against three tests: does the generated admin shell survive contact with our brand, does the Spatie Permission wiring match our role model, and how many generated files would we rewrite in month one. If the answer to the third is "most of them," we go to Filament and this becomes a reference implementation rather than a dependency.