Black Dashboard Laravel Package

Product Decisions This Supports

• Build vs. buy for the "day one" admin surface. This is not a runtime dependency — it's a one-time scaffolder (php artisan ui black-dashboard) that copies auth views (login, register, password reset, email verification) and a Bootstrap 4 admin theme into resources/views and public/. The real decision it informs is "do we spend 1–3 engineer-days hand-wiring an authenticated admin shell, or copy a pre-built one and edit it?" Because the output lands in your repo as plain Blade + CSS/JS, exit cost is near zero. That asymmetry (cheap to try, cheap to throw away) is the decision-relevant fact.
• Roadmap sequencing for internal tooling. Justifiable when the first milestone is "an admin can log in and see the thing," not "we have a design system." Good fit for back-office CRUD shells, ops dashboards, tenant admin panels, and client-facing reporting portals built by agencies on Laravel.
• Audience-tier decision. Appropriate where the UI buyer is internal staff or an SMB client accepting a stock Bootstrap admin look. Not appropriate where brand, accessibility conformance, or a component library roadmap is a stated product requirement — the theme is a fixed cosmetic layer with no upgrade path you control.
• Team-skill fit. A rational choice for PHP-first teams with Bootstrap fluency and no desire to stand up Tailwind/Vite build pipelines or learn Livewire/Inertia. It preserves a Blade-only mental model, which is a real hiring and maintenance cost saving.
• Adoption-risk weighting. 87 stars, 0 dependents, last release Nov 2024. Treat this as sample code with a convenient installer, not a supported product. That should push the decision from "add a dependency" to "budget for owning a fork on day one" — which is fine, but it must be explicit in the plan.
• What it should not decide. Architecture, auth implementation, or permission model. It only swaps presentation scaffolding; authorization, tenancy, and API design decisions remain untouched.

When to Consider This Package

Reasonable fit when:

• You're on Laravel 11/12 with laravel/ui, using Blade (not Inertia or a Livewire-first stack), and need authenticated screens within days.
• Bootstrap 4 is acceptable to the business — i.e., no design system mandate and no near-term Bootstrap 5 migration on the roadmap.
• The team is small, the audience is internal or a single client, and "good enough admin chrome" beats "custom design."
• You're producing a prototype, POC, or demo where the cost of rebuilding the UI later is already budgeted.
• You explicitly accept ownership of the generated files and the Bootstrap 4 lifecycle.

Look elsewhere when:

• Bootstrap 5, Tailwind, or a maintained component library is required. Bootstrap 4 is end-of-life; any long-lived product here inherits a migration project. Prefer Laravel Breeze (Tailwind) or Filament / Livewire-based admin kits for maintained, actively-updated UI.
• You need ongoing vendor support, security patches, or upgrade paths. Zero dependents and a single low-traffic repo mean you are the maintainer. Plan accordingly or don't adopt.
• Livewire, Inertia, or SPA/SSR is the intended architecture. This preset targets server-rendered Blade only.
• Accessibility, i18n/RTL, or brand conformance is a hard requirement. A stock Creative Tim theme gets you a look, not a compliance story.
• Public-facing or high-scale surfaces. Fine for internal; weak for customer-facing product UI where iteration velocity on components matters.
• You already run the standard Bootstrap preset. Marginal gain collapses to theme assets — just vendor the CSS.

Before committing, verify: that the preset command actually runs against your laravel/ui version (the "11.x and up" claim is inexpensive to make and presets are notoriously sensitive to Laravel skeleton changes), and that the bundled theme assets carry their own permissive license separate from the package's MIT — check both, since the theme is upstream of this repo.

How to Pitch It (Stakeholders)

To executives: This is a free, MIT-licensed starter kit that gets our Laravel admin screens — login, registration, password reset, dashboard shell — standing in roughly a day instead of a week of engineering. There's no license cost, no vendor contract, and no runtime dependency: the generated files live in our repository, so we can walk away at any time with nothing to unwind. The trade-off is cosmetic and deferred, not structural: it uses an older Bootstrap version, so if the admin surface becomes long-lived or customer-facing, we'll budget a UI refresh later. Recommended use is internal tools and early-stage admin panels, where the savings are real and the downside is a reskin, not a rewrite.

To engineering: Run php artisan ui black-dashboard on Laravel 11/12 with laravel/ui; it scaffolds auth Blade views and publishes Bootstrap 4 assets. Treat the output as your code — fork it, don't depend on it. Two constraints to accept up front: Bootstrap 4 is EOL, so no new components from that ecosystem without a migration decision, and there is effectively no upstream community (0 dependents, ~87 stars) — assume no fixes will arrive from the maintainer. Verify the preset command against our exact Laravel and laravel/ui versions in a throwaway branch before we commit, and pin the theme assets into our repo rather than relying on the package installer at build time.