Tomato Builder Laravel Package

Technical Evaluation

Architecture fit. The package presents two mutually exclusive identities, and a TPM cannot scope either until that ambiguity is retired. The marketing description advertises a Tailwind/Vue drag-and-drop page builder; the packaged documentation describes a visual CRUD/schema designer that scaffolds models, migrations, and Filament resource screens. These are different products with different persistence models, different end users, and different risk profiles. The first deliverable of this evaluation is not an installation — it is a one-day code read (service provider, migrations, Vue entry point, config) that answers which product we are actually evaluating. That half-day is the cheapest risk retirement available and should be scheduled before any sprint capacity is allocated.

Integration feasibility. Feasible only under narrow conditions: a stack already on Laravel + TomatoPHP/Filament + Tailwind + Vue, where integration cost approaches zero. Outside that, we are importing a second frontend paradigm (Vue alongside Livewire or React) with a reactive-seam cost that is real but hard to estimate up front. The package's advertised extension points — a field-type registry and configurable output templates — are legitimate hooks, but they should be exercised through an internal adapter layer (PageRepository / BlockRenderer) so that no controller or Blade view calls package classes directly. That adapter is what buys a swap path, and it is the single most valuable architectural commitment we can make here.

Technical risk. High, and concentrated in abandonment rather than code quality. Ten stars, zero dependents, and a last release of December 2023 mean essentially no independent production validation against Laravel 11/12, Filament 3.x, Livewire 3, or Tailwind 4. Zero dependents means we are the QA. Secondary risks: an undocumented, unversioned content shape (a migration liability); Tailwind JIT purge stripping classes that exist only in database rows (the classic "works in staging, breaks in prod" failure for this class of package); and an XSS/CSP surface inherent to non-developer-authored HTML and inline styles. MIT licensing makes vendoring legitimate and legally clean, but it obligates no one upstream — the maintenance obligation transfers wholly to us.

Key questions for the evaluation gate.

1. Which product is it — page builder or CRUD scaffolding generator? This resets stakeholder expectations either way and must be answered first.
2. What framework versions does the 2023 tag actually pin (Vue 2 vs 3, Vite vs Mix, Tailwind 2/3 vs 4)? A stale pin may force a choice between forking an upgrade and freezing the rest of our stack.
3. What is the persisted content shape, and is it losslessly exportable? If we cannot write an export command, we have no escape hatch.
4. Does production render survive Tailwind purge with caching enabled?
5. Who on staff owns this fork, and is that a funded line item or an assumption?

Integration Approach

Stack fit. Proceed only if the environment is Laravel + Filament + Tailwind + Vue. If the frontend is React or Livewire-only, decline early — the cost is not integration, it is paradigm reconciliation, and that is not a TPM-sized bet on a 10-star dependency.

Migration path. There is no meaningful migration from an existing builder on the strength of this package. If we already run GrapesJS, Puck, or bespoke Blade blocks, adopting this is a lateral move into an unmaintained dependency, not an upgrade. The honest framing is greenfield-only or not at all, for content that is structurally simple (landing pages, CMS blocks, admin-managed content) rather than complex application UI.

Compatibility. Pin an exact tagged release — an unpinned composer require on a repo with no releases since 2023 resolves to a moving target that will never move again, or worse, to a branch head. Record and publish the tested matrix (PHP, Laravel, Filament, Livewire, Node/Vite, Vue, Tailwind) as a decision-document artifact, because a 2023 tag is likely stale on at least two of those axes and future upgrades will need that baseline.

Sequencing. Time-boxed and gated, with explicit stop conditions:

1. Day 1 — scope audit. Resolve page-builder vs. CRUD-generator. If code and stakeholder pitch diverge, stop and reset expectations.
2. Days 2–5 — contained POC. One low-stakes marketing landing page, or one small resource with 3–5 mixed field types, built and rendered end-to-end through the real production path with caching on and Tailwind's production build enabled.
3. Decision gate. Proceed only if the POC shows correct production render (including class survival), acceptable UX for a real non-technical editor, and a clean lossless export.
4. Rollout behind a feature flag. Marketing pages first, then CMS content, then anything user-facing — with the existing editor intact throughout.

Prefer the scaffold-and-own mode if the code turns out to be the generator: run it once, commit the output, and treat it as our code. Only take builder-at-runtime if the persisted payload is JSON we can inspect and transform, and only with an adapter, a schema_version column, and tagged cache invalidation wired in the same sprint.

Operational Impact

Maintenance. Assume we own the code from day one. Fork under an internal namespace, track upstream as a reference implementation, and write the fork policy down before the first cherry-pick. Realistic budget: two engineers able to read the Vue source, persistence layer, and render path (a single-person bus factor is an organizational risk, not just a technical one), at 10–20% of one engineer for two quarters to stabilize, then steady dependency-bump and security-patch work thereafter. That cost belongs in the business case, not in a footnote.

Support. There is effectively none. No vendor, no SLA, no active upstream. Internal support means a named owner, a runbook, and the debugging checklist (dump raw payload → render through a bare route → grep compiled CSS → disable cache → check published assets) documented before launch rather than discovered during an incident.

Scaling. Fine for low-traffic marketing surfaces. If the builder renders a stored block schema client-side through Vue, we inherit bundle size, hydration cost, and per-publish CDN invalidation — and we should push the render path server-side (a Blade component per block type over a JSON schema) wherever the package allows, to recover normal Laravel caching, SEO, and CDN behavior. Cache invalidation must be tagged per record, never a flush, with a fallback so one broken page degrades instead of 500-ing the section.

Failure modes to plan for. Tailwind purge stripping stored classes; Vue/Livewire asset load-order and event collisions; schema-shape drift with no version field; sanitization stripping content on write (or, worse, not stripping it); silent loss of published assets after filament:assets / optimize. Mitigate with a CI smoke test that creates a record, saves, renders through the production route, and asserts a representative builder-emitted class survived — that single test catches the purge, render-route, and schema-shape regressions together.

Ramp-up. Low for the install, moderate-to-high for the codebase. Expect a half-day for the scope read, three-to-five days for the POC, and roughly a sprint for a second engineer to reach real proficiency with the Vue layer and persistence shape. Plan for editor-persona validation early — put the tool in front of an actual marketing or ops user during the POC, because "does this UX satisfy our editors?" is the question the spike exists to answer, and it is the one question no amount of code reading will settle.