Tomato Forms Laravel Package

Product Decisions This Supports

• Scoping "let admins define their own forms." Any roadmap item that sounds like custom profile fields, onboarding questionnaires, intake/KYC flows, internal surveys, or per-tenant custom attributes is the same underlying shape: form → fields → answers stored against the user record instead of new columns. This package is a working reference implementation of that data model, which lets you size the work in days and argue from a concrete artifact rather than a whiteboard.
• Build vs. buy vs. fork, settled on evidence. The surface is small — two Filament resources, a few migrations, likely one controller — and MIT-licensed. That collapses the usual three-way debate. A form SaaS is hard to justify for a bounded internal need; a straight dependency is hard to justify at zero stars and zero dependents; fork-and-own is the credible middle path, and this repo is the thing that makes that case in the room.
• Keeping schema churn off the core user model. Answers land in user meta rather than typed columns, so product can add, retire, reword, or A/B question sets without a migration or a release. Treat that as a design principle independent of whether you adopt this package — it's the real product insight, and it's what makes per-plan and per-region variation cheap.
• Buying signal on the "no-code admin" theme cheaply. If ops users authoring their own data capture is on the roadmap, a one-to-two-day spike here returns real evidence on authoring UX, permissioning, and the definition-vs-submission permission split before you commit a quarter of engineering.
• Deciding where not to spend engineering. Form builders are commodity. This package does not meaningfully cover conditional branching, multi-step flows, versioned schemas, typed exports, or integrations — those are the differentiators, and that is where the team's time belongs.
• Forcing the storage decision into writing. Whether user meta is the system of record or a staging area is a product call with long-tail consequences — reporting, billing, compliance, deletion rights, migration cost. Make it explicitly now, before responses accumulate and the cost of changing your mind goes up.

When to Consider This Package

Consider it when:

• You are already inside the TomatoPHP / Filament admin ecosystem and want a drop-in rather than an integration project.
• The forms are internal, admin-authored, low-traffic, and non-critical: back-office intake, internal surveys, ops data capture, HR requests.
• You are prepared to vendor and fork under MIT — treating upstream as a starting point and accepting ownership of maintenance, patching, and Filament-major compatibility.
• You need a prototype in days to validate a workflow before committing to an in-house build; "is this feature worth a quarter?" gets answered for the price of a spike.
• Your team has Laravel/PHP capacity to audit the migrations, the validation layer, and authorization on both form definition and form submission.

Look elsewhere when:

• The forms are customer-facing or touch sensitive data. Runtime-defined schema plus key/value meta needs a real security review: mass assignment, authorization over which fields a given user may submit, stored XSS in admin-authored labels and options, file uploads, PII retention and deletion. None of that is guaranteed here.
• You need capabilities it does not advertise — conditional logic, multi-step flows, schema versioning, typed reporting/exports, or third-party integrations. Building those on top costs more than starting fresh.
• You need durable vendor support or a compatibility commitment. Last release was May 2024, it predates Filament v4, and there are zero dependents — assume the package is dormant and that maintenance ownership transfers to you in full.
• Submissions are system-of-record data for billing, compliance, or audit. Key/value meta with no schema versioning means reports silently drift after any field rename or retype; that's an unacceptable failure mode for regulated or revenue-critical records.
• Your team has no Filament/PHP depth. The realistic endgame is owning this code; adopting it without the capacity to read and patch it is borrowing technical debt at a high rate.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel package that gives us a working model for letting admins define their own forms — profile fields, intake questionnaires, internal surveys — without database migrations every time a question changes. The strategic value is not the code; it's that we can price the "configurable data capture" roadmap item from a real artifact instead of an estimate, and run a two-day spike to decide whether that theme deserves a quarter of engineering. The honest caveat: it's a single-maintainer project with no dependents and no release since May 2024, so we would be adopting it as a starting point we own, not a supported dependency. Recommended posture is internal-only, off the critical path, and never in front of customers or sensitive data until a security review clears it.

To engineering: Treat this as a fork candidate, not a composer require. The surface is tiny — a couple of Filament resources and a handful of migrations — so the realistic endgame is vendoring under MIT and owning the maintenance. Before any integration code: confirm the Filament major constraint matches ours, read the migrations as the API, and audit the submit path for whether it writes unprefixed keys into a shared user-meta table (silent data-loss bug, highest-severity item here). Plan a thin repository seam between our app and the package's tables so the authoring UI survives a storage change, re-validate submissions server-side rather than trusting stored validation config, namespace every meta key, and assume no cascade cleanup when a form or field is deleted. First milestone is a five-field internal intake form rendered in Blade for two users — half a day, and it answers every open question about render path, meta shape, and whether we're forking.