Tomato Laravel Package

Product Decisions This Supports

• Capacity reallocation on commodity surfaces. TomatoPHP is a Laravel/Filament admin-panel accelerator: CRUD generation, auth scaffolding, roles and permissions, menus, settings, and a media manager ship out of the box. The PM decision it enables is narrow but real — compress the first two to four weeks of back-office scaffolding into days so engineering capacity moves to the product surface customers actually pay for. It does not accelerate revenue-path features.

• Build vs. buy on undifferentiated tooling. For internal dashboards and low-risk data-management screens, the honest comparison is not "TomatoPHP vs. from scratch" — it is "TomatoPHP vs. plain Filament's make:filament-resource," which is already fast. Frame the decision that way in the business case. The measured delta, not the marketing pitch, should drive the call.

• MVP sequencing and time-to-first-demo. Useful where a working internal demo unlocks stakeholder feedback or budget faster than a bespoke build. It can pull forward internal-tool deliverables on the roadmap. It should not be used to justify pulling forward customer-facing commitments without a separate risk review.

• Market entry where RTL is a requirement. The bundled Arabic/English localization and RTL support is the one capability that is genuinely expensive to replicate and rarely free in a Laravel starter. If the roadmap includes MENA-facing back-office surfaces, this is a defensible reason to look — and a line item to price against a custom i18n effort.

• Dependency governance and risk posture. 162 stars, zero recorded dependents, a low opportunity signal (0.15), and a last release of 2024-04-29 against annual Laravel/Filament majors are portfolio-level inputs. They support classifying this in the dependency register as a tactical tool with bounded scope — not a strategic platform bet — with a named owner and a documented exit path.

• Staffing and onboarding economics. Standardized CRUD conventions help Laravel-standardized junior-to-mid teams move fast. The helper-heavy design ("tonnes of functions") lowers the cost of writing code and raises the cost of reading it — a maintenance tax that lands in a later quarter's budget, not this one's.

• Decisions this should not drive. Anything touching customer data, revenue paths, compliance scope, systems of record, multi-tenancy, granular authorization, or auditability. The absence of an upgrade policy, community support, or downstream adopters makes those decisions indefensible in architecture or procurement review.

When to Consider This Package

Consider it when:

• The surface is internal and low-blast-radius: admin panels, ops dashboards, back-office CRUD, simple data-management screens with no external users.
• The team is already on Laravel/PHP and standardized on or willing to adopt Filament v3, running Laravel 10/11 and PHP 8.1+ today — with no Laravel 12 upgrade inside the current planning horizon. Make framework version a hard intake gate, not a conversation.
• The dominant cost is repetitive CRUD boilerplate, not domain complexity, integrations, performance, or authorization nuance.
• The work is greenfield. There is no incremental path — retrofitting the module system and helper layer into a live application is a rewrite in disguise. Acceptable for a new internal tool; disqualifying for anything in production.
• RTL/Arabic admin localization is a roadmap requirement, making the bundled i18n support a real line-item offset rather than a nice-to-have.
• You can commit to a bounded pilot with a pre-committed decision gate: hours saved against a plain-Filament baseline, defect density in generated code over four weeks, time for a second engineer to onboard, and the outcome of a one-day upgrade rehearsal.
• You can contain the coupling: generator-only usage, isolated behind your own module boundary, with generated output treated as ordinary reviewed application code.
• You accept an exit path as a staffing commitment. MIT licensing makes fork-and-maintain possible — someone owns it, and that time is budgeted.

Look elsewhere when:

• The package would sit in a customer-facing, revenue-critical, compliance-sensitive, or internet-exposed path.
• You need a supported dependency: active maintenance, security responsiveness, published upgrade policy, commercial backing, SLA. Zero dependents means you are first to discover every incompatibility, in your own sprint.
• The product needs complex workflows, heavy integrations, multi-tenancy, granular authorization, auditability, or performance tuning beyond standard CRUD.
• You need predictable upgrades across Laravel/Filament majors. A ~one-year staleness gap against an annual cadence is a schedule risk to the next platform upgrade.
• The team would be locked into TomatoPHP-specific conventions (plugins, global helper API, module registry) rather than standard Laravel patterns.
• Procurement or architecture standards require vendor due diligence, SBOM/security review, and community support. Weak market signal makes this hard to defend.

How to Pitch It (Stakeholders)

Executive summary. TomatoPHP is a Laravel CRUD scaffolding framework with a Filament-based modular admin panel. The upside is real but narrow: it can compress the first two to four weeks of standard back-office scaffolding — auth, roles and permissions, menus, settings, media, resource screens, plus Arabic/RTL localization — into days, on internal tooling only. The downside is structural rather than incidental: effectively single-maintainer, zero dependents, no release since April 2024, no upgrade policy, no commercial support. The recommendation is a two-week, single-engineer spike with a pre-committed decision gate and a hard fallback to plain Filament — and explicitly not a platform decision.

For engineering. Evaluate it as a code-generation workflow, not a runtime dependency. Build one real internal tool end to end and measure hours saved against the honest baseline — plain Filament, which is already fast — because the delta may be materially smaller than the pitch. Contain it: isolate behind a module boundary, prefer generator-only usage so committed code is ordinary Laravel, pin Laravel/Filament/PHP explicitly, commit the lockfile, and record the tested matrix in the repo README. Ban regeneration in CI — regeneration overwrites hand edits and produces silent regressions once generated code has been touched. Run a one-day upgrade rehearsal before shipping anything real; it is the highest signal per hour available. Watch for global helper name collisions producing third-party stack traces and inflated MTTR: namespace your own code and forbid undocumented helper use.

For product. Use it where speed matters and failure is contained — internal dashboards, ops tooling, early MVPs with no external users. The product decision is to buy speed on commodity surfaces while protecting the core product from dependency risk. Concretely: fund the spike against a pre-agreed baseline, approve only internal tooling for the first two quarters, and require a named owner plus a documented exit path before any second use. Do not let generated CRUD mask domain complexity — scaffolds that make data look simple are how under-modeled domains reach production. And do not let a successful spike become an implicit platform standard: retrofitting success criteria after the fact is how a tactical tool turns into a strategic accident.

On cost, state it plainly. The spike's low cost does not imply a low steady-state cost. Budget ongoing maintenance, upgrade exposure at each Laravel/Filament major, and the fork option as a real staffing line — MIT licensing converts "locked out" into "you own it," which is risk transformation, not risk elimination.