Tomato Admin Laravel Package

Product Decisions This Supports

• Build vs. buy for the back-office. Tomato Admin is a pre-assembled admin scaffold — a FilamentPHP-derived theme layered on Laravel Splade — shipping authentication, users/roles/permissions, settings, menus, widgets, and a CRUD generator. It reframes the admin question from "build from scratch or license Nova" to "assemble from an accelerator." The decision it informs is whether the team spends three to six weeks on plumbing or defers that cost in exchange for carrying a small dependency.
• Roadmap sequencing and v1 scope. Login, user tables, roles, and settings exist on day one, so early sprints can go to domain features instead of table stakes. That directly changes what you can credibly commit to for a first release and clarifies how much of the schedule is differentiation versus floor.
• Standardizing internal tooling. One theme and component set across multiple internal apps shrinks the design and QA surface. This supports a consolidation decision — moving three or four ad-hoc admin tools onto a single stack rather than maintaining each independently, and giving ops/support users one interface to learn.
• Feature triage and capacity allocation. Low-value-but-required admin CRUD (audit views, settings editors, user management, media handling) becomes cheap, freeing engineering capacity for revenue-facing work. That's the cleanest ROI argument available: it buys back time for work customers actually notice.
• An explicit stack bet. Adopting it is really a decision to standardize internal surfaces on Laravel + Livewire/Filament + Splade (Vue 3). That has downstream consequences for hiring, code review standards, frontend tooling, and onboarding time — and it should be made as a deliberate architecture decision, not quietly inherited from a package choice.
• Scoping a pilot. It's a good vehicle for a one- to two-week internal-tool spike to test whether a Filament-based admin is sufficient before committing to a bespoke SPA. Success criteria are concrete: one internal ops screen shipped, rendering behind your own auth guard, with a production asset build.
• What it does not decide. This is an internal velocity lever, not a differentiator. It should never appear in customer-facing positioning, competitive analysis, or pricing conversations, and it doesn't offset the need for a frontend platform decision elsewhere.

When to Consider This Package

Consider it when:

• You're on a current Laravel version and want a working admin panel in days, and the team is comfortable with Blade/Livewire or willing to learn it.
• The surface is internal and low-blast-radius — ops consoles, support tools, CMS-lite, internal reporting — where a stale dependency is an annoyance rather than a P0 incident.
• You're prepared to fork and own it. The MIT license permits vendoring and divergence freely; that should be the plan from day one, not the fallback after the first upgrade breaks the theme.
• You're consolidating several hand-rolled internal tools and want a single shared shell, or you want a working reference for a Filament theme plus Splade integration to copy patterns from even if you never depend on the package.

Look elsewhere when:

• You need production support, SLAs, or guaranteed security patching. The signals — roughly 56 stars, zero dependents, a mid-2024 last release, and a single-maintainer ecosystem — describe a project you would carry yourself. Verify release cadence and issue responsiveness before betting a roadmap on it.
• The admin is customer-facing or touches regulated data. There you want a large, scrutinized dependency surface: vanilla FilamentPHP, Laravel Nova, or a well-maintained commercial template with a security channel.
• Your team is React/Next-native. Splade (Vue) plus Livewire is a hard stack commitment, and running a second frontend paradigm for one screen set is a real tax on hiring and velocity.
• You need API-first or headless administration, or heavy multi-tenant scale. This is an opinionated, monolith-side dashboard, not an admin API.
• You can't fork-and-own it. Consumed as an untouchable dependency through routine composer update, the risk-to-return profile is poor.

If you adopt: pin the version, fork into your org, budget roughly 10–15% of one engineer to track three upstreams (Laravel, Filament, Splade), and keep domain logic in your own packages so a future swap to vanilla Filament is a re-skin rather than a rewrite.

How to Pitch It (Stakeholders)

For executives. This is an MIT-licensed admin dashboard accelerator for Laravel with zero license cost. It adds no customer-facing features; instead it removes roughly three to six weeks of back-office plumbing (login, roles, settings, menus, CRUD screens) from the first release. The risk is maintenance, not money: it's a small, young project in a single-vendor ecosystem with no production dependents we can point to today. So the ask is not to adopt a supplier — it's to approve a timeboxed spike and a fork-and-own policy, with success measured as one internal ops screen shipped and an exit cost we're comfortable paying.

For engineering. Treat it as a starting point we intend to own, not a dependency we consume. Expect a one-week spike: stand it up against a production build in a throwaway app, mount it behind our own auth guard, and prove the Tailwind/asset pipeline before writing any feature code — that's where schedules slip. Plan on roughly one to two weeks of ramp for a mid-level Laravel developer, since this requires both the Livewire/Alpine server-driven model and the Vue/Splade client-driven one. Keep business logic in our own modules behind the admin screens; that single constraint makes replacing the shell later a re-skin instead of a rewrite.

For finance and procurement. No license line item, no vendor contract, no per-seat cost. The budget question is purely internal engineering time: a fixed spike, then a maintenance allocation of roughly one-fifth of an engineer ongoing. That compares favorably against a commercial admin license plus the three-to-six-week build alternative — but the comparison only holds if we plan to own the fork rather than depend on upstream support.