Bootsjet Starter Kit Laravel Package

Product Decisions This Supports

• Build vs. buy (scaffold vs. greenfield): Choosing a starter template is a one-time bootstrapping decision, not a runtime dependency. This release makes the tradeoff explicit: Jetstream Livewire + Teams + Bootstrap scaffolding for free, versus weeks of wiring auth, teams, Vite/Sass, and CI yourself.
• Front-end design system direction: The package is Bootstrap-first, not Tailwind-first. This is a strategic signal for teams with an existing Bootstrap-based design system, brand guidelines, or in-house Bootstrap component libraries — it lets product and design stay aligned with established UI standards instead of retrofitting Tailwind.
• Multi-tenant / team-based product roadmap: Jetstream's Teams feature being pre-configured directly enables products with organizations, seats, invitations, and role-based access — useful when the roadmap includes B2B or collaborative features from day one.
• Feature scope and time-to-first-demo: Livewire ^3 || ^4 compatibility (no forced downgrade on Laravel 12) means the team isn't blocked by dependency pinning, reducing risk in sprint planning for the first milestone.
• Release/quality gating for new projects: The included CI (Composer validate, frontend build, PHPUnit) plus a validated end-to-end installer flow gives a baseline quality bar, reducing the "works on my machine" tax on day one.
• Standardization across new products: If the org spins up multiple Laravel apps, mandating a single starter kit reduces per-project setup drift — a governance and onboarding decision.

When to Consider This Package

Consider it when:

• You are starting a new Laravel 12 application from scratch (this is a starter template, not an installable library for existing apps).
• Your team is standardized on Bootstrap and/or has an existing Bootstrap design system.
• You need auth, teams, and profile management out of the box via Jetstream Livewire.
• You want Sass + Vite already wired (resources/sass/app.scss).
• You value a reproducible one-command install (laravel new ... --using=...) over hand-assembling a boilerplate.
• You're comfortable with a v0.1.0, community-maintained project and can audit the code before adoption.

Look elsewhere when:

• You want the Laravel ecosystem default of Tailwind CSS (use the standard Laravel starter kits or Breeze instead).
• You need vendor-backed support, SLAs, or long-term maintenance guarantees — this is a single-maintainer community repo at first stable release.
• You need to retrofit an existing application — starter kits cannot be applied to running projects.
• You require enterprise compliance, licensing review, or security audits before adopting third-party scaffolds (license and security posture aren't documented in the release notes).
• Your product doesn't need Jetstream/Teams — the built-in multi-tenancy and Livewire stack may be unnecessary weight you'd have to strip out.
• You expect a documented upgrade path across Laravel major versions; starter kits typically require manual re-scaffolding or diffing.

How to Pitch It (Stakeholders)

To executives: This is a free, open-source Laravel starter kit that gets a new product from zero to a working, tested application — complete with authentication, team management, a Bootstrap UI, and CI — in a single command. It reduces initial build time and standardizes how we launch Laravel projects. Risk is low because it's a scaffold we copy, not a runtime dependency we're locked into; we can fork it and own it. The main caveat is that it's a young, community-maintained project, so we should do a short technical audit before standardizing on it.

To engineering: Adopt this as the default scaffold for new Laravel 12 projects where Bootstrap is the chosen UI framework. It ships Jetstream Livewire with Teams pre-configured, Vite + Sass, and a CI pipeline, and installs via laravel new my-project --using=m1ge0/bootsjet-starter-kit — no bootsjet:swap step. Livewire ^3 || ^4 means no forced downgrade. Because it's a starter template, the "dependency" ends at project creation: fork it, pin a commit/tag, and treat upgrades as deliberate re-scaffolds or diffs rather than Composer updates. Flag any team that needs Tailwind — they should use the standard Laravel kits instead.