Flirt Kit Laravel Package

Product Decisions This Supports

• Build vs. buy for the scaffolding layer. flirt-kit is not a runtime library — it's a skeleton application you fork. That makes it a direct substitute for the 2–4 engineer-weeks a team typically burns standing up auth, layout, routing conventions, and an admin panel. The decision it informs is "do we spend headcount on boilerplate, or start from an opinionated baseline?"
• Time-to-first-demo / MVP scope. Because it ships a RILT front end (React + Inertia + Laravel + Tailwind) and a Filament v4 admin panel in one repo, it collapses two normally separate workstreams — customer-facing UI and back-office CRUD — into a single starting point. This is a scope decision: fewer parallel tracks, faster first internal demo.
• Admin-panel strategy for internal and back-office tools. Filament is a strong fit for ops tooling, moderation queues, and internal CRUD. If a roadmap item is "give the ops team a console," this repo is a credible day-one answer rather than a 6-week project.
• Use cases where it fits: internal tools, agency/client starter templates, admin-heavy SaaS back offices, prototypes that may or may not graduate, and teams already standardized on Laravel + Filament who want a consistent front-end convention.
• The score tension is itself a signal. Opportunity is high (0.86) — there's a real gap for opinionated Laravel + Inertia/React + Filament starters — while overall score is low (0.06), driven by 12 stars, zero dependents, and a single maintainer. That combination means market gap, unproven vendor. It supports a "spike and fork" decision, not a "standardize the org on it" decision.
• Roadmap implication: if you adopt it, you are implicitly committing to owning a fork. That's a maintenance line item on the roadmap, not a one-time setup cost.

When to Consider This Package

Consider it when:

• You are starting a greenfield Laravel app and need both a React/Inertia front end and an admin panel — this eliminates a genuine two-front problem.
• Your team already knows Laravel and Filament; the value is conventions and saved setup time, not learning a new abstraction.
• You are building internal or back-office tooling where upgrade cadence and vendor SLAs are not audit requirements.
• You have a time-boxed MVP or client deliverable where shaving a week off setup changes the ship date.
• You are comfortable forking and owning the code — patching Laravel/Filament upgrades yourself and treating the repo as a snapshot, not a dependency.
• You want a reference architecture to crib from, even if you don't adopt it wholesale.

Look elsewhere when:

• You need a maintained dependency with a security-response commitment. 12 stars, zero dependents, and one maintainer means no community safety net and no expectation of a CVE turnaround.
• The product has a multi-year lifespan with strict upgrade SLAs. Skeleton apps rot quietly — Laravel major versions and Filament v4→v5 migrations land on your team, not the maintainer.
• Your team is Blade/Vue-only or has no Filament experience; the saved setup time gets eaten by ramp-up.
• You need enterprise concerns — multi-tenancy, SSO, audit logging, compliance packaging — that a starter kit implies but doesn't guarantee.
• You specifically want Filament v3 stability; v4 is recent and the ecosystem around it is still settling.
• You want a composable library rather than a whole application opinion. Adopting a skeleton means adopting someone else's folder structure and conventions wholesale.

How to Pitch It (Stakeholders)

To executives: This is an MIT-licensed starting template, not a paid product — zero license cost. The business case is cycle time: it replaces roughly two to four engineer-weeks of scaffolding with a working application that already has a React front end and a functioning admin panel on day one. The right framing is "cheap experiment," not "platform decision." Ask for a one-to-two day engineering spike to validate fit; approve broader use only after that returns green. Be explicit about the trade: a 12-star, single-maintainer project means we own the code and the upgrades once we fork it.

To engineering: flirt-kit is a Laravel skeleton wired for the RILT stack with Filament v4 as the admin panel. You fork it, pin your PHP/Lumen/Filament versions, and treat the upstream as a one-time snapshot — not a Composer dependency you'll pull updates from. The conventions are the product: routing, Inertia page structure, and a Filament resource layer that's already wired. Budget explicitly for ownership — tracking Laravel and Filament majors is now our job, and the repo's low adoption means upstream fixes won't arrive on their own. Evaluate it against our own laravel new baseline and timebox the comparison.

To the adopting team: Use it if it matches your stack today. If you're on Filament v3, or your front end is Vue or Blade-first, the fit is poor enough that a custom scaffold is likely cheaper than the adaptation work.