Tomato Splade Laravel Package

Product Decisions This Supports

• Build vs. buy for internal admin surfaces. tomatophp/tomato-splade is a Blade-first SPA starter kit (Vue 3 + Inertia under the hood) with pre-built profile/admin pages and publishable views. The decision it informs is not "SPA or not" but "assemble our own admin component layer vs. adopt this curated fork." For back-office CRUD, dashboards, and settings screens it removes a meaningful chunk of scaffold work.
• Frontend rendering strategy for internal tooling. It lets a Laravel-heavy team ship SPA-feeling navigation while authoring Blade, keeping routing, validation, and server-side rendering logic in PHP. That is a hiring and skills decision as much as a technical one — it favors backend-strong teams over Vue/React specialists, and it should be decided once at the platform level, not re-litigated per project.
• Ecosystem consolidation. If the org already runs TomatoPHP packages, this is the natural admin/auth/table/form layer and can standardize scaffolding across products. If it does not, the value over upstream protonemedia/laravel-splade drops to "a few extra components" and the consolidation argument disappears.
• Time-to-first-release on client and internal builds. The "selected updates" and ready-made pages are a real velocity lever on small internal builds — quantifiable as setup hours, build-pipeline hours, and time to first working admin module.
• Roadmap sequencing and risk budgeting. With 2 stars, 0 dependents, and a last release of 2024-04-29, the honest framing is: this is an accelerator to pilot behind a feature flag, not a platform bet. The roadmap decision is whether to fund a named steward for a thin internal fork — including upstream diffing, security patching, and Laravel major-upgrade headroom — or to treat the savings as not worth the ownership.
• Procurement and dependency policy. For orgs with a security-review gate, this package will not clear a "community-vetted dependency" bar today; the PM decision is whether to seek a policy exception for internal-only tooling or route around it.

When to Consider This Package

Consider it when:

• The team is already fluent in Laravel, Blade, Vue 3, and Inertia and wants SPA navigation without writing Vue single-file components day to day.
• You are inside — or deliberately standardizing on — the TomatoPHP ecosystem, so the curated components and admin conventions actually compound.
• The target is internal, non-customer-facing tooling (admin panels, back-office CRUD, dashboards) where no vendor SLA, no SEO requirement, and no enterprise support contract apply.
• You accept adoption means pinning versions, mirroring or vendoring the package, diffing against upstream Splade, and owning patches — treating it as a starting point, not a supported dependency.
• You can assign a named steward and absorb their recurring time as a real line item.

Look elsewhere when:

• You need active maintenance, a security-patching cadence, or a documented upgrade path. Release history and adoption are thin and the fork's divergence from upstream is undocumented.
• Your security review or procurement process mandates community-vetted dependencies with meaningful adoption, contributor depth, or commercial support.
• The frontend direction is React/Next.js or Livewire — Splade's Blade + Vue model would fragment the stack for no offsetting gain.
• You need SSR or SEO-critical public pages; keep marketing and public surfaces on a different stack.
• You cannot fund fork maintenance. Small forks lag upstream Splade and Laravel releases, and a Laravel major can block upgrades outright.
• The app is a standalone Laravel project not otherwise touching TomatoPHP — upstream Splade gives you the same core model with better odds of community support.

A sensible pattern: a time-boxed pilot on one internal module, wrapped behind your own layout and wrapper components so the underlying library can later be swapped for upstream Splade or an in-house layer.

How to Pitch It (Stakeholders)

To executives: Tomato Splade is an MIT-licensed Laravel starter kit that pairs Blade templates with Vue and Inertia to deliver modern, SPA-feeling admin interfaces without maintaining a separate frontend application. Frame it as an accelerator for internal tooling, not a platform commitment. There is no license cost; the real cost is modest but genuine engineering ownership. Recommend a scoped pilot with an explicit go/no-go checkpoint rather than org-wide adoption.

To engineering leadership: It provides a curated set of components, admin/profile pages, and updates on top of Laravel Splade, cutting boilerplate for auth, tables, forms, and dashboards — a real velocity gain for backend-heavy Laravel teams. The trade-off is maturity and supply chain: very low adoption (2 stars, 0 dependents), a single-maintainer profile, no release since April 2024, and an undocumented delta from upstream. Mitigations are straightforward and cheap if done up front: pin all versions, mirror or fork it internally, diff against upstream to track divergence, isolate fork-specific components behind your own wrappers, and document an exit path. Assign a named steward — without one, the fork silently rots against Laravel releases and the application inherits an upgrade freeze.

Pilot success metrics to review at the gate: delivery time for the first admin module, setup and build-pipeline hours, bundle size and time-to-interactive on realistic pages, number of fork-specific patches required, and engineering hours spent on support. Approve broader adoption only if those numbers beat the alternatives you actually had (upstream Splade, standard Inertia + Vue, or a hand-rolled Blade/Livewire admin).

Bottom line: High leverage for small, internal, Laravel-centric teams that accept ownership and are committed to the TomatoPHP admin stack; not appropriate where support commitments, security review, or long-horizon maintenance guarantees are required.