Splade Laravel Package

Product Decisions This Supports

• Build vs. buy for admin/SPA layer: This is an early signal in the "Blade-first SPA" category — relevant if we're deciding between building our own Blade + Vue admin shell, adopting Inertia, or picking up a pre-built package. At v0.0.1 it is a watch-list input, not a build-vs-buy verdict.
• Roadmap hedge for internal tooling: If our roadmap includes internal admin panels, CRUD back-offices, or Laravel-based dashboards, this is a candidate to spike against our existing stack rather than a commitment.
• Ecosystem bet: It sits in the TomatoPHP orbit, so adopting it is partly a bet on that vendor's plugin ecosystem and release cadence — a decision that affects future dependency and support posture, not just one feature.
• Feature scoping: Helps answer "does a single Blade-based SPA toolkit remove enough custom JS work to justify a dependency?" — a scope-reduction question we can now test cheaply.
• Not supported by this release: Anything requiring stability guarantees, SLAs, security posture, or upgrade-path planning. A 0.0.1 tag with a changelog that is only a commit link gives us no deprecation, migration, or feature detail to plan against.

When to Consider This Package

Adopt for evaluation (timeboxed spike, isolated branch) only when all of these hold:

• The target app is Laravel on a currently supported PHP version, and the team is already comfortable in Blade + Vue rather than committed to Inertia/React or a full JS SPA.
• The work is a greenfield internal tool or a non-critical admin surface where a breaking change costs hours, not revenue.
• We are already, or are deliberately considering, standardizing on the TomatoPHP ecosystem, so the shared conventions and plugin surface compound rather than add a second paradigm.
• We want to reduce hand-written front-end glue and are willing to pin an exact version and own the upgrade diff ourselves.

Look elsewhere when:

• The surface is customer-facing, revenue-critical, or subject to compliance/security review — a 0.0.x version number is a de facto statement that the public API will move, and there is no changelog substance to assess risk.
• The team has standardized on Inertia, Livewire, Filament, or a separate front-end repo; introducing a parallel rendering model costs more in cognitive load than it saves.
• We need documented support, a security disclosure path, or upgrade guidance — none of which can be inferred from a release note that contains only a compare link.
• We would be the first production adopter. With no prior assessment data and no populated changelog, we would be doing the vendor's hardening work.

How to Pitch It (Stakeholders)

For executives (one paragraph): A small open-source Laravel package called Splade just cut its first public release, version 0.0.1. It targets the recurring cost of building admin panels and internal dashboards by giving Laravel teams an SPA-like experience without a separate front-end application. The strategic value is optionality, not adoption: it is a cheap, low-risk experiment that could shave custom front-end work off internal tooling. The risk is equally clear — a 0.0.1 release with no real changelog means no stability, support, or upgrade commitments. Recommendation: fund a one-to-two sprint, isolated spike; do not put it on a customer-facing path, and do not treat this as a vendor selection decision yet.

For engineering (the ask): Stand up a throwaway branch, pin the exact version, and build one representative CRUD screen plus one non-trivial form. Success criteria are concrete: how much bespoke JS we deleted, how the package behaves on our PHP/Laravel matrix, and how readable the upgrade diff is. Wrap it behind our own thin abstraction so a swap-out is a contained change, and log a go/no-go with a named owner and a review date tied to the next release or two. Treat anything learned from a 0.0.1 as directional; re-assess once the project ships a populated changelog and a stable minor version.