Tomato Builder Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork for page authoring. This package puts a concrete third option on the table — MIT-licensed, self-hosted, Laravel-native — to weigh against a custom block editor, a commercial SaaS builder (Builder.io, Storyblok, Contentful), or deferring the problem entirely. The real decision isn't "should we composer require this?" It's "are we prepared to own an editor?" That question is worth forcing into the open regardless of what we choose.
• Resolving scope before committing engineering time. The package ships two conflicting identities: the marketing description advertises a Tailwind/Vue drag-and-drop page builder, while the packaged documentation describes a visual CRUD/schema designer that scaffolds models, migrations, and resource screens. These serve different users, different roadmaps, and different risk profiles. A one-day code read settles which one we're actually evaluating — and that discrepancy is the cheapest risk to retire in the entire assessment.
• Content-velocity roadmap. If it's the page builder, it targets the recurring bottleneck of marketing and landing-page changes queuing behind engineering sprints. If it's the CRUD scaffolding tool, it addresses internal-tool build speed — a real but narrower win. Both are defensible; conflating them in a roadmap review is how timelines slip.
• MVP and internal-tool scoping. A credible path to putting a working authoring surface in front of stakeholders in weeks, for prototypes, admin panels, and low-traffic pages where speed of learning matters more than long-term maintainability.
• Editor-persona validation. Lets us test whether non-technical editors (marketing, ops, regional teams) are a genuinely funded segment — and surface what they actually need (approvals, localization, SEO controls, audit trails) versus what a generic builder provides out of the box.
• Risk-register entry and decision record. Adoption signals — 10 stars, 0 dependents, last release December 2023, health score 0.21 — belong in the technical-risk section of a written product decision doc, not buried in a Slack thread. A named decision with a rationale ages far better than tribal memory.
• Roadmap optionality through a time-boxed spike. Framing the spend as a bounded evaluation (scope audit → contained POC → go/no-go gate) buys real information — does this UX satisfy our editors? does it survive production rendering? — without locking the roadmap to an unmaintained fork.
• Fork-vs-depend budgeting. MIT makes vendoring legally clean; it does not make it free. Every evaluation should answer "would we staff this code?" That's a resourcing decision for the PM, not a technical detail for the engineer.

When to Consider This Package

Consider it when:

• Your stack is already Laravel + TomatoPHP/Filament + Tailwind + Vue. Integration cost approaches zero and you aren't importing a second frontend paradigm into the app.
• You need a demonstrable authoring surface — MVP, internal tool, or low-traffic marketing pages — within weeks rather than quarters.
• License cost is a hard constraint, or procurement/data-residency rules make an MIT, self-hostable option preferable to a SaaS page builder.
• You are prepared to fork and own it: pin an exact version, audit the component set, and carry ongoing maintenance as a real line item.
• The content is structurally simple — landing pages, CMS blocks, admin-managed content — not complex application UI.
• You want a tangible artifact to put in front of stakeholders before committing budget to a custom build.

Look elsewhere when:

• The surface is production-critical, high-traffic, or carries accessibility, compliance, or SLA obligations.
• You need active maintenance, security patching, or vendor support. A December 2023 last release with zero dependents is a strong abandonment signal — and "zero dependents" means essentially no independent production validation against Laravel 11/12, Filament 3.x, Livewire 3, or Tailwind 4.
• Your frontend is React or Livewire-only. You'd be introducing a competing reactive paradigm where bugs concentrate.
• Requirements include SEO controls, i18n, content versioning, editorial approvals, audit trails, A/B testing, or a headless content API. These are almost certainly out of scope and become custom work layered on top of an unmaintained base.
• Content portability matters. The package-defined persistence shape becomes a migration liability if it's undocumented and unversioned.
• No engineer has appetite to own a fork. In that case a maintained commercial builder or a narrow in-house block system is the lower-risk call.
• The scope question can't be resolved. Conflicting descriptions are a caution flag until audited — don't spend against ambiguity.

How to Pitch It (Stakeholders)

To executives: This is not a platform commitment — it's a cheap information purchase. For roughly one day of engineering to resolve what the package actually is, plus a three-to-five-day contained proof of concept, we get a definitive answer on whether a self-hosted, no-license-cost page authoring tool can remove the marketing-changes-queue bottleneck. The downside is bounded and the alternative — a custom build or a SaaS contract — is a multi-quarter or recurring-revenue decision we'd be making with the same unanswered questions.

To engineering: Treat this as a fork-and-own candidate, not a dependency. Ten stars, zero dependents, no release since December 2023 means we are the QA, the security patcher, and the framework-upgrade path. MIT makes vendoring legitimate; it obligates no one upstream. Sequence it as: half-day code read (service provider → migrations → Vue entry point → config) to settle page-builder vs. CRUD-scaffolder → pin an exact version on a throwaway branch → one page end-to-end through the real production render path with Tailwind's production build and caching on. Proceed only if classes survive purge, content round-trips losslessly, and the editor UX holds up for a real non-technical user. Put an adapter between our app and the package so a swap is a one-file change, add a schema_version column and an export command in the same sprint, and write the smoke test that asserts a builder-emitted class reaches the HTML in CI. Budget honestly: 10–20% of one engineer for two quarters to stabilize, then steady dependency-bump and patch work — and avoid a single-person bus factor on a forked dependency.

To the editor community / internal stakeholders: The value proposition we're testing is "you can change this page without filing a ticket." What we don't yet know is whether the tool's actual editing experience — and the governance around it (approvals, localization, SEO) — meets your needs or just moves the ticket queue somewhere else. The POC exists to answer that with your hands on the keyboard, not with a slide deck.