Tomato Components Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for back-office UI. This package is a ready-made component kit for Splade and TomatoPHP admin surfaces. The decision it informs is whether to assemble internal screens from a third-party kit, fund an in-house component set, or fork this MIT-licensed code and own it. All three are viable; the maintenance math decides.
• Standardizing the admin stack. Choosing Splade + TomatoPHP (rather than Filament, Inertia, or Livewire) is a foundational, hard-to-reverse platform bet. This package only pays off inside that bet, so evaluating it is effectively a proxy for deciding whether Splade + TomatoPHP is our internal-tools stack for the next 12–18 months.
• Time-to-market for internal tooling. The core value is delivery speed on CRUD screens, dashboards, settings pages, moderation queues, and back-office workflows — work that generates no direct revenue but blocks ops, support, and sales demos. A reusable kit compresses that cycle and reduces dependency on scarce frontend headcount.
• Design-system ownership. Adopting a shared component set is a decision about whether we want one consistent look and behavior across internal surfaces or per-team reinvention. It is also a decision about who owns that consistency after launch.
• Roadmap sequencing and capacity allocation. Adopting implies budgeting an owner for the fork and periodic upgrade work; declining implies budgeting in-house component work instead. Either way it is a real line item, not a free dependency.
• Dependency and vendor-risk policy. Zero stars, zero dependents, no meaningful release notes (v1.0.3's changelog is a compare link and nothing else), a last release in February 2023, and a thin maintenance signal make this a useful precedent test for whether our policy tolerates lightly-maintained packages in production paths. The decision here should set policy, not become an exception.

Honest read: the opportunity is real — admin UI is a genuine, repeatable cost center, and the opportunity score (4.16) reflects that even though the overall confidence score (0.46) does not. The package's health metrics are weak. Treat it as code to acquire and own, not a dependency to install and forget.

When to Consider This Package

Consider it when:

• We have already chosen Splade for rendering and/or TomatoPHP as our admin panel. Outside that stack the components have little or no reuse value, and an Inertia, Livewire, Filament, or bespoke-Blade app will spend more time stripping Splade-specific markup than writing its own.
• The scope is internal tooling — back-office CRUD, dashboards, settings, moderation — where a consistent baseline UI matters more than bespoke design, and where a silent visual regression is an annoyance rather than an incident.
• We are willing to vendor or fork it: assign a named owner, pin an exact version (1.0.3, with the lockfile committed), and accept that upstream will likely never ship a fix on our timeline. The MIT license makes this straightforward.
• The component surface is small enough for one engineer to audit in a day or two — plausible for a kit of this vintage, but something to verify against resources/views/components/, not assume.
• We need a starting point or reference implementation more than a supported product — something to copy patterns from, not something to composer require and forget.
• We can validate it cheaply: rebuild one screen we already have in plain Blade, time both, and treat a delta under roughly 20% as a signal that the kit costs more in ownership than it saves in keystrokes.

Look elsewhere when:

• We are building a customer-facing product, public SPA, or anything with an availability commitment. An unmaintained package in a revenue path is an avoidable liability.
• We are on Inertia, Livewire, Alpine, or Filament. Overlap is near zero and migration cost dominates any benefit.
• We need a support contract, security patch cadence, or compatibility guarantees with future Laravel/Vue majors. Compatibility here is unverified, not verified-good — the declared constraint ranges are the only evidence available.
• We already have an internal design system or component library. Two component systems is worse than one imperfect one.
• The team cannot absorb fork maintenance. If nobody owns it, the components rot in place and become a quiet drag on every upgrade.
• We need long-lived accessibility, internationalization, or browser-support guarantees — there is no documentation or test suite to point to as evidence, and RTL support is the only stated i18n affordance.

How to Pitch It (Stakeholders)

For executives: We are evaluating a free, MIT-licensed UI kit that could shorten delivery of internal admin screens — the settings, dashboards, and CRUD pages that consume engineering time but never appear on a roadmap. The catch is that it is a zero-star package with a single maintainer, no changelogged release notes, and no release since February 2023. That means we would not be "buying a product," we would be acquiring source code and owning it. The proposal is therefore deliberately scoped: a short, time-boxed spike on one existing screen to measure actual delivery savings, followed by a go/no-go. If the savings are real, we copy the handful of components we actually use into our own namespace under the MIT license, assign an owner, and drop the Composer dependency. If the savings aren't real, we've spent a few days and learned something about our admin stack. Either way this decision also sets precedent for how we treat lightly-maintained open source in production-adjacent paths — which is worth deciding deliberately rather than by accident.

For engineering: This is a Splade/TomatoPHP Blade component kit, not a framework. It buys us consistent markup for common admin patterns — cards, alerts, modals, forms, tables — and nothing else. The recommended path is: verify Splade or TomatoPHP is already in composer.json; pin 1.0.3 exactly and commit the lockfile; read resources/views/components/ directly because there is no documentation and that directory is the catalogue; then rebuild one known-good screen to time the delta. Two things will bite us and should be planned for, not discovered. First, Tailwind will silently drop the package's utility classes unless we add vendor/tomatophp/tomato-components/resources/views/**/*.blade.php to our content globs — the component renders unstyled, not broken, which is worse. Second, Splade ships its own card, modal, and alert; name collisions resolve by load order and fail silently with props quietly ignored, so we alias everything through x-admin-* and wrap each component we adopt rather than calling it directly. Because upstream ships no tests, we own a smoke test per component and three to five browser tests over the screens that use them. For anything load-bearing, copy the Blade source into our own namespace on day one — before the first break, not after — and keep the component inventory, pinned version, and fork point in the README next to a named owner. The likeliest failure mode here isn't a breaking change; it's that nobody notices it's broken until three admin screens look wrong and nobody remembers installing it.