Sparky Laravel Package

Product Decisions This Supports

Whether to standardize a "golden path" for admin and back-office apps. Sparky is a Laravel starter kit consumed once (composer create-project, or more realistically a fork), not a runtime dependency. So this is not a vendor-onboarding decision — it's a platform decision: is one opinionated starting point better than the 3–10 days each squad re-derives on every greenfield Filament build? Made once, applied many times, or not at all.

Speed-to-first-screen on CRUD/admin-heavy work. The kit targets the undifferentiated early effort: auth, panel scaffolding, resource generation via Filament Blueprint, Boost tooling, form/table conventions, seed data, and a Pest 4 harness (feature/browser/architecture). The relevant number is hours-to-first-real-feature versus your current baseline, measured on one genuine vertical slice — model, migration, factory, resource, filters, relationship form, test.

The admin-layer stack bet (Filament / Livewire 4 / Tailwind 4 / Alpine). Adopting it implicitly commits internal tooling to Filament. That carries hiring implications, component-library choices, and how much custom Blade we write. It belongs in a platform review, not a per-project one — and it should be decided deliberately rather than inherited by whoever scaffolds the next app.

Our AI-assisted development standard. The most underrated angle: the bundled agents/skills/ tree (Flux UI, Livewire 4, Pest 4, Tailwind 4) encodes house conventions as machine-readable guidance, so coding agents generate code in existing patterns instead of inventing them. If we are rolling out coding agents, a kit that ships binding skills is a guardrail product. The decision it supports: "agent-authored PRs follow the shipped skills, and review-churn rate on agent PRs is the success metric."

Build-vs-buy input for an internal platform template. Even if we ultimately build our own, this is a cheap reference implementation of what that output looks like — including its opinionation (Blueprint for generation, Boost for tooling, skills for agents). It is a specimen to diff against laravel new, not a product to subscribe to.

A decision-blocking caveat to raise before any spend is approved: the public description describes a dependency-free inline-SVG sparkline charting library for Filament tables and dashboard widgets; the repository, the v0.1.0 release, and the bundled skills tree describe a Filament starter kit. These are different products with different risk profiles and different stakeholders. At 13 stars and zero dependents there is no ecosystem signal to triangulate against — the pinned commit is the only source of truth. Verify the artifact first; then escalate the metadata, because it will confuse the next engineer and it will confuse any agent we point at the registry. If the sparkline library turns out to be the real thing, this collapses into a two-hour utility evaluation with no fork and no platform implications.

When to Consider This Package

Adopt — as a fork pinned to a commit, never as a live dependency — when:

• You are greenfield. Starter kits are the wrong tool for retrofit; the entire value is in the initial scaffold, and the conventions are expensive to impose mid-flight.
• Your admin stack already is, or is deliberately becoming, Filament + Livewire. If admins are an Inertia/Vue/React surface, the kit's opinions actively fight you.
• You want current-generation conventions wired together — Livewire 4 component formats, Tailwind 4 CSS-first config, Pest 4 architecture tests — and would rather inherit one coherent take than assemble four separate upgrade guides.
• You accept opinionation as the product. Track the deletion rate during evaluation: the percentage of the kit you keep versus delete is the best proxy for fit. Deleting 40% means the kit is fighting you and you should have installed Filament directly.
• You need a credible UI fast for an internal ops dashboard, client admin portal, data-management tool, or an MVP on a moving schema.

Look elsewhere when:

• You need billing, teams, invitations, or subscription gating. SaaS scaffolding is explicitly out of scope; budget it separately rather than discovering it missing in week two.
• You need a maintained dependency with an upgrade path. One release, one maintainer, no stated upgrade policy. Filament and Livewire ship majors quickly; a copied tree with no upstream diff path means every major becomes a manual, coordinated migration you own end to end.
• You wanted sparkline charts. Read the description mismatch above before anything else — if that is your actual requirement, evaluate the artifact that renders charts, not a starter kit.
• Procurement or security review requires a supported vendor. No dependents, no release cadence, no CVE channel. Fine as an internal fork; not fine as something you promise a customer will be patched.
• You need a low-risk, reversible trial. The kit is consumed whole, so the honest framing is a fork with a migration treadmill attached — not a dependency you can drop in an afternoon.

Evaluation gate, written down before anyone starts: one engineer, one week, one real feature. Success criteria agreed up front — hours-to-first-feature versus baseline, percentage of kit kept versus deleted, and defect plus review-churn rate on agent-authored PRs. Downside is capped at one week, and the output feeds the build-vs-adopt call either way.

How to Pitch It (Stakeholders)

To executives: This is not a purchase and not a vendor relationship. It is a template we copy once and own forever — the question is whether copying it is faster than the two-to-three weeks of scaffolding each team currently re-derives for every internal admin tool. The exposure is bounded: one engineer, one week, explicit success criteria, and we walk away with a build-vs-adopt answer regardless of outcome. The main risk to note is that the package's public description does not match what the repository actually contains; we verify the pinned commit before anyone commits budget.

To engineering leadership: The kit bundles Filament, Filament Blueprint, Boost, and a set of agent skills for Flux UI, Livewire 4, Pest 4, and Tailwind 4 into one coherent convention set. The skills are the differentiator — they give coding agents a machine-readable house style instead of letting them invent one per PR. It also forces a decision we've been deferring: whether internal tooling standardizes on Filament. It is greenfield-only, it will not cover billing or multi-tenancy, and we should fork and pin it rather than track upstream, because there is one maintainer and one release.

To the evaluating engineer: Start by confirming what is actually in the pinned commit — the registry text and the repository disagree, so trust neither and read the tree. Expect to write your own migration path for future Filament and Livewire majors, to grep for Flux Pro components before shipping, and to diff every generated resource against what a hand-written one would look like so you can tell a deliberate convention from an opinion nobody agreed to. Come back in a week with three numbers: hours to first feature, percentage of the kit you kept, and review-churn on agent PRs.