Tomato Laravel Package

Technical Evaluation

TomatoPHP is an opinionated application scaffold, not a library: a modular Laravel admin panel on Filament, a CRUD/file generator, and a broad global-helper surface. A TPM should frame adoption as a scope-and-conventions decision with staffing and upgrade-path consequences, not a routine Composer addition an individual engineer makes alone.

Architecture fit. Narrow but predictable: greenfield, internal-facing, CRUD-dominant admin surfaces on a Filament stack. In that envelope it can compress the first two to four weeks of scaffolding — auth, roles/permissions, menus, settings, media, resource screens — into days. Outside it, reject fast: existing Laravel apps, API-first services, non-Filament UIs, and anything requiring multi-tenancy, granular authorization, auditability, or complex workflow gain nothing from the generators while inheriting the module system, directory conventions, and helper surface. The helper-heavy design ("tonnes of functions") is the specific TPM flag — it lowers the cost of writing code and raises the cost of reading and onboarding, a maintenance tax paid by a future team and a future budget.

Integration feasibility. Mechanically low-friction: Composer install, publish config, scaffold. The real constraint is version coupling. A layer this deep into Filament and Laravel pins specific majors, and both ship breaking majors on roughly annual cadences. The last release (April 2024) sits in the Laravel 10/11 and Filament v3 era, so the planning question is not "will it install this sprint" but "will it install on the framework version we run in four to six quarters." With zero recorded dependents, no downstream population absorbs and reports that upgrade pain — we would be first to discover it, in our own sprint, on our own clock.

Technical risk. Structural rather than incidental, and each item maps to a TPM decision:

• Bus factor. Effectively single-maintainer. 162 stars and zero dependents is an audience, not a community — a support-model risk, not a code-quality one.
• Staleness signal. No release in roughly a year against a one-year framework cadence is a leading indicator. Treat it as schedule risk to the next platform upgrade, not to this quarter's delivery.
• Code generation as a liability. Generated CRUD is a snapshot of the generator's opinions. Once output is hand-edited, regeneration either overwrites work or stops happening and the generator becomes archaeology — constraining how we staff and iterate.
• Global namespace surface. Third-party-owned helpers and a plugin registry create collision and upgrade-ordering problems that are hard to attribute during an incident — an on-call and MTTR concern.
• Weak market signal (162 stars, 0 dependents, low opportunity score). Consistent with a project neither growing nor being adopted. The risk is not disappearance tomorrow; it is quiet drift from upstream while we are committed.
• Mitigating factor. MIT means the failure mode is "fork and maintain," not "locked out." That is a real option, but a staffing commitment that must be costed as such.

Key questions before commitment.

1. Which Laravel and Filament majors are supported today, and is there a published upgrade policy? (A README claim is not an answer; a release is.)
2. Is the value in the generator (one-time, disposable) or the runtime modules and helpers (ongoing, lock-in)? Only the latter creates dependency risk.
3. What is actual maintenance activity — commit cadence, issue response time, open-PR age over the last six months?
4. Are there production references beyond the author's own projects?
5. Can we adopt a subset — generator only, no runtime helper dependency — and keep coupling shallow?
6. Who owns a fork if upstream stalls, and is that person's time cheaper than building the equivalent ourselves?

Integration Approach

Stack fit. Target stack is Laravel 10/11, PHP 8.1+, Filament v3, MySQL/Postgres. If we are on Laravel 12 or plan that upgrade inside the current planning horizon, this is a non-starter until upstream ships support. Make that a hard gate in the intake checklist rather than a conversation.

Migration path. There is no incremental path. This is greenfield scaffold or nothing — retrofitting the module system and helper layer into an existing application is a rewrite wearing an integration costume. Acceptable for a new internal tool with no users yet; disqualifying for anything in production. State this plainly in the decision record so it is not relitigated mid-sprint.

Compatibility. Every transitive constraint is a hard gate. Pin Laravel, Filament, and PHP explicitly, commit the lockfile, and record the tested matrix in the repo README. No floating constraints on a single-maintainer package — a silent minor bump is how a Friday becomes interesting, and the TPM owns the resulting schedule slip. Isolate the package behind our own module boundary and forbid undocumented helper use in our own code so collision incidents are attributable.

Sequencing. Run it as a bounded experiment with a pre-committed decision gate, not an adoption:

1. Spike (1–2 weeks, one engineer). Build one real, low-blast-radius internal tool end to end. Measure actual hours saved against the honest baseline — plain Filament with make:filament-resource, which is already fast. The delta may be materially smaller than the pitch.
2. Containment. Where feasible, use only the generator and discard the runtime helper dependency so committed code is ordinary Laravel. This converts a framework bet into a one-time productivity loan — the single most valuable structural move available.
3. Upgrade rehearsal (1 day). Before shipping anything real, dry-run a Filament or Laravel minor upgrade in the spike repo and record what breaks. Highest signal per hour of any test we can run.
4. Decision gate (pre-agreed metrics). Hours saved vs. baseline, defect density in generated code over four weeks, time for a second engineer to onboard, and the rehearsal outcome. Decide go/no-go in writing before the gate, not after the data arrives.
5. Bounded rollout. First two quarters, internal tooling only. A named owner and a documented exit path are prerequisites for any second use.

Operational Impact

Maintenance. Budget steady-state cost explicitly; a cheap spike does not imply cheap ongoing maintenance. Two recurring line items: (a) keeping the pin matrix current as Laravel/Filament move, and (b) reviewing generated code as ordinary application code rather than trusting the generator. Ban regeneration in CI — it overwrites hand edits and produces silent regressions — and treat any regenerated diff as a reviewed change with an owner.

Support. There is no commercial backing, no SLA, and no published upgrade policy; GitHub issues from a single maintainer are the entire support surface. Operationally that means our own engineers are tier-1 through tier-3, and the escalation path when upstream is unresponsive is the fork. Record that in the dependency register as "tactical tool, bounded scope" so procurement and architecture review see the classification rather than rediscovering it.

Scaling. Fine for internal tools with modest user counts and standard CRUD load. It is not the place to solve performance tuning, heavy integrations, multi-tenancy, or auditability — the helper layer obscures query behavior, and the module system adds indirection that makes profiling harder. Plan to scale by leaving the envelope, not by tuning within it.

Failure modes and early indicators.

• Helper name collision surfacing as a third-party stack trace → inflated MTTR during an incident. Mitigate with namespacing and a forbid-list.
• Upstream drift — no release covering the next Laravel/Filament major → blocked platform upgrade. Early indicator: no upstream release within one cadence window of a framework major.
• Generation archaeology — generator no longer runnable against current dependencies, output now effectively hand-maintained → quietly converts to a fork whether or not we decided to fork.
• Onboarding tax — a second engineer takes materially longer to become productive than on plain Laravel. This one is cheap to measure in the spike and is the best proxy for the maintenance tax.
• Platform creep — a successful spike becomes an implicit default for new work. Counter this by writing the scope boundary into the decision record at gate time.

Ramp-up. Helpful for Laravel-standardized junior-to-mid teams that benefit from standardized CRUD conventions and gain speed from the generators immediately. The cost lands later and on different people: the helper-heavy API and module conventions raise the reading cost for anyone who did not write the original scaffold, and the single-maintainer dependency raises the cognitive load on whoever owns upgrades. Staff the exit path — one named owner with budgeted time to fork and maintain — before the second project adopts it, not after.