Tomato Admin Laravel Package

Technical Evaluation

Architecture fit. Tomato Admin is an opinionated, monolith-side back-office accelerator: a FilamentPHP-derived theme layered on Laravel Splade, shipping auth, users/roles/permissions, settings, menus, media, and a CRUD generator. The architecture that fits is a server-rendered Laravel app whose admin surface is internal — ops consoles, support tooling, CMS-lite. It does not fit API-first/headless products, heavily multi-tenant deployments, or any surface where the admin is customer-visible. The single most consequential architectural fact for a TPM is that adoption is a stack bet, not a package pick: it commits the team to Livewire/Alpine and Vue 3/Splade simultaneously. That has downstream consequences for hiring, code review norms, and frontend build ownership, and should be recorded as an explicit architecture decision rather than inherited quietly from a composer require.

Integration feasibility. Mechanically straightforward (Composer package, MIT, publishable config/assets, migrations) but organisationally it is an ecosystem commit. Sibling packages — settings, roles, forms, translations — are designed to compose, and the trap is shallow adoption of five rather than deep adoption of two. Feasibility hinges on three unknowns that must be answered before any schedule is committed:

• Does composer.json require filament/filament outright, or is only the theme vendored? That single answer decides whether you inherit the full Filament resource engine or merely a UI shell — and it changes the build-vs-scaffold estimate materially.
• Which Filament major (v3 vs v4) and which Splade version the views were written against.
• What guard, user model, and route prefix the shipped routes and config assume.

Technical risk. The risk is concentrated in the front end and in ownership, not in PHP:

• Tailwind preset collision between Filament and Splade is the number-one schedule risk. It routinely passes in dev and fails only in minified production builds — a late-discovery failure mode that can consume a sprint.
• Splade SPA routing vs Livewire lifecycle produces stale component state after navigation; the hardest bug class to reproduce, and the one most likely to burn engineering hours.
• Silent breakage on upgrades. A Filament major bump degrades styling with no exception thrown; a Splade bump can yield a blank dashboard with no useful stack trace. Neither is caught by unit tests.
• Project maturity. ~56 stars, zero dependents, last release mid-2024, single-maintainer ecosystem, no evident security policy or CVE channel. Treat every dependency in the chain as ours to patch.
• Asset publish drift. Filament themes publish to public/; if the pipeline rebuilds rather than ships them (or vice versa), staging serves stale assets with no error surfaced anywhere.

Key questions to resolve before approval.

1. Is the target surface strictly internal and low-blast-radius? If it touches regulated data or customers, this is the wrong dependency profile and I would route to vanilla Filament or Nova.
2. Who owns the fork, and is fork-and-own funded from day one rather than treated as a fallback?
3. What is the exit cost if we swap to vanilla Filament in twelve months — i.e. are we enforcing the discipline of keeping domain logic out of package-owned code?
4. Do we have a visual smoke test (even screenshot diff) budgeted, given that the two most likely regressions are invisible to automated tests?
5. Does the team's existing frontend competence include Vue/Splade and Livewire, or are we accepting a context-switch tax?

Integration Approach

Stack fit. Target Laravel + Livewire/Alpine + Vue 3 via Splade. If the team is React/Next-native, taking on two additional frontend paradigms for one internal screen set is a poor trade — a React-based admin is the better call. If the team is already Blade/Livewire-comfortable, fit is good and the value proposition (three to six weeks of plumbing removed from the first release) is credible.

Migration path. Do not install into the existing production app first. Sequence:

1. Week 1 spike in a fresh matching-version Laravel app. Deliverable: the dashboard rendering behind our auth guard with a compiled production build — not php artisan serve. Run the production build on day one, not day ten, specifically to force the Tailwind collision to surface inside the timebox.
2. Fork and vendor into a private repo with an UPSTREAM.md. This is the default workflow, not a contingency. Pin the version; upstream diffs happen on a scheduled manual cadence, never on composer update.
3. Wire into the real app in parallel, mounted under a distinct /admin prefix with its own layout and its own Vite entrypoint (and, where possible, its own Tailwind config) so the Filament/Splade preset merge cannot break the customer-facing app. Feature-flag the rollout: internal users first, then a cohort.
4. Vertical slice before breadth: users table + login end-to-end. That one slice exercises auth, middleware ordering, asset publishing, the Tailwind build, and the Splade shell simultaneously. If it works in production-mode compilation, the remainder is largely repetition.

Compatibility. Pin Laravel constraint, Filament major, and Splade version together as a set and treat them as a single upgrade unit. Confirm config/auth.php guard name matches what the package expects, confirm the user model binding, and confirm middleware ordering (auth before panel middleware) — a guard mismatch locks the team out on first deploy and presents as a routing bug.

Sequencing and team pattern. Establish the scaffolding pattern on day two, with documentation. If the full Filament resource engine is present, make:filament-resource is the path; if only the theme layer shipped, duplication of the package's Users resource is the path. Write the internal "how to add a CRUD screen" doc while copying the reference files. Register navigation the same way the shipped screens do — no second navigation system. Keep business rules, exports, and integrations in our own modules that admin screens call into; that single constraint is what makes a future swap a re-skin rather than a rewrite. Adopt two sibling packages deeply (roles and settings are the natural picks) rather than five shallowly.

Operational Impact

Maintenance. Budget approximately 10–15% of one engineer ongoing. The driver is not this package's release cadence — it is that the fork tracks three moving upstreams (Laravel, Filament, Splade) while the package tracks none of them on our schedule. Add a defined quarterly upstream-diff slot and a standing owner. If that allocation cannot be secured, the honest recommendation is not to adopt.

Support. There is no SLA, no vendor, no security policy, and no evident CVE channel; zero dependents means no crowd-sourced bug surface to lean on. For internal ops consoles that is an acceptable posture because we are effectively the maintainer of record. It is not acceptable for customer-facing or regulated-data surfaces, where a larger, scrutinised dependency is the better bet. Communicate this to stakeholders as a maintenance cost, not a licensing cost — the ask is approval of a timeboxed spike plus a fork-and-own policy, not the selection of a supplier.

Scaling. This is an opinionated monolith-side dashboard. It scales adequately across breadth — standardising three or four ad-hoc internal tools onto one theme and component set shrinks the design and QA surface, which is one of the cleanest arguments for adoption. It does not scale into headless/API-first requirements, heavy multi-tenancy, or high-concurrency public traffic patterns.

Failure modes to instrument for.

• Silent theme degradation after a Filament major bump — no exception, no test failure. Mitigation: screenshot diff or manual visual checklist on every upgrade gate.
• Blank dashboard after a Splade bump from Vue component registration — surfaces only in production. Mitigation: pinned versions, post-deploy smoke check against /admin.
• Staging-only asset drift — works locally, looks wrong in staging, no error logged. Mitigation: decide and document on day one whether the pipeline ships published assets or rebuilds them, and never mix.
• Guard/user-model mismatch — first-deploy lockout that reads like a routing bug. Mitigation: test the login flow itself, not just post-login render.
• Stale Livewire state on Splade-navigated pages. Mitigation: learn the SPA opt-out mechanism early and apply it liberally to Livewire-heavy pages.

Ramp-up. Plan 1–2 weeks to productivity for a mid-level Laravel engineer; the cost is carrying two mental models at once (server-driven DOM morphing for Livewire/Alpine, client-driven SPA routing for Vue/Splade). Do not staff this with a React/Next-native engineer without explicitly accepting the context-switch tax. Onboarding artefacts worth producing: the day-two CRUD doc, the assets-ownership note, a debugging checklist (clear config/route/view caches after publish → confirm published theme assets present → confirm correct guard → confirm the production build's Tailwind content globs include package views → confirm provider registered → confirm Filament major matches the views), and the ranked extension-point policy: config first, view overrides second, container bindings third, vendored-source edits only inside the fork.

What I would track as TPM. Spike exit criteria (screenshot of /admin behind our guard, production build); the fork created and UPSTREAM.md live; a named maintenance owner at 10–15%; a visual smoke test in the release gate; at least one internal ops screen shipped to a real user cohort; and an explicit, written exit cost for migrating to vanilla Filament. This package is an internal velocity lever — it frees capacity for revenue-facing work — and should never appear in customer-facing positioning, competitive analysis, or pricing conversations.