Tomato Model Generator Laravel Package

Product Decisions This Supports

• Build vs. generate for back-office CRUD. The package converts a field list typed at a CLI prompt into an Eloquent model plus a matching migration, with $fillable, $casts, and belongsTo/hasMany wiring filled in. That gives a PM a concrete cost comparison to put in front of a squad: hand-write the model layer per entity, or generate it and spend the saved hours on the logic that actually differentiates the product.
• Roadmap scoping for internal tools. When each additional admin surface costs hours instead of days, the roadmap conversation shifts from "can we afford this screen?" to "which entities are in scope this quarter?" That is a scoping decision, and it is the single biggest lever this package offers.
• Time-to-demo. A guided generator compresses schema-to-clickable-prototype, which matters for pilots, stakeholder reviews, and anything where you need feedback on a data model before committing real engineering. Fast scaffolding buys more feedback loops per quarter.
• Convention standardization as a governance choice. The package is described as following TomatoPHP conventions and is customizable via stubs. Publishing those stubs lets a team codify naming, file layout, and relationship patterns once. The decision it supports is whether structural consistency is enforced by tooling or audited by code review — relevant when onboarding developers or when review keeps catching the same drift.
• Ecosystem sequencing, not a standalone pick. Adoption is a soft commitment to the TomatoPHP/Filament stack. Treat it in the same decision as your admin-panel framework choice, not as an isolated library evaluation — the leverage comes from fit, not from the generator alone.
• Pilot metrics to commit to up front. Cycle time per entity (generated vs. hand-built), number of post-generation corrections, and percentage of generated files that survive first review unmodified. Those three numbers decide rollout or kill; feature lists do not.
• What this release does not support. v1.0.1 (2024-03-28) is a patch with a bare changelog compare link and no described changes. Treat it as a maintenance signal only. It should not anchor a roadmap commitment, a release note, or a stakeholder promise about capability.

When to Consider This Package

Consider it when:

• You are already on — or deliberately evaluating — the TomatoPHP/Filament admin stack. That is where the leverage lives; outside it, native Laravel generators do the same job with less discovery cost.
• Your backlog contains repeated CRUD admin surfaces and the cost is measurable — multiple entities per sprint, or a queue of internal requests that never clears.
• You want convention enforcement across several developers and manual review is not catching structural drift in models and migrations.
• The schema is young and volatile. Regeneration is cheap relative to hand-maintenance when tables change weekly.
• The work is internal tools and back-office, where speed and consistency outrank bespoke UX.
• You can run a timeboxed spike with a defined exit. Output is plain Laravel code, so vendor risk is bounded rather than open-ended.
• Your team would otherwise hand-roll a small internal generator — this is a cheaper starting point than building one, provided the conventions roughly match.

Look elsewhere when:

• The domain is complex or non-CRUD — heavy workflows, event-sourced systems, multi-tenant policy layers. Generators emit a starting point, not an architecture, and the scaffolding becomes dead weight fast.
• Generated output would be immediately rewritten. You pay integration, learning, and review cost for code you throw away.
• You need vendor stability, SLAs, or auditable release notes. Zero stars, zero dependents, a single undocumented patch release, and a 0.33 composite score are genuine procurement signals, not formalities.
• Security or compliance review requires every line to be authored and traceable. Generated paths nobody wrote are hard to defend in an audit.
• You need relationship inference beyond the basics. Composite keys, polymorphic relations, and custom column types are the standard failure modes of interactive generators, and this one publishes no evidence to the contrary.
• The Filament/Laravel/PHP version constraints in composer.json do not match your stack. A version mismatch is the most likely first-install failure — check before spending evaluation time.

How to Pitch It (Stakeholders)

For executives: This is a developer-productivity tool for our Laravel admin tooling. It generates the boilerplate behind back-office screens — models, migrations, fillable fields, casts, and relationship wiring — so engineers spend their hours on business logic instead of repetitive setup. The decision it supports is build vs. generate for internal tools: with a queue of admin surfaces, it can take each one from days to hours and standardize how all of them are built. The cost is a dependency on a small, community-maintained package with no adoption history and an undocumented last release; the risk is that generated code still requires human review before it ships. The downside is bounded — the output is plain Laravel code we keep whether or not we keep the tool. Recommendation: timebox a one-entity pilot on a non-critical internal tool, measure it against the hand-built baseline, and standardize only if it wins.

For engineering leads:

• What it is: a build-time Artisan generator in the TomatoPHP ecosystem that emits Laravel model-layer artifacts — model classes, migrations, $fillable, $casts, and belongsTo/hasMany relationships — from an interactive prompt flow, with publishable stubs and config for team conventions. It is not a runtime dependency: no request-path latency, no production failure mode, no uptime surface.
• Fit: strong if we are on Filament/TomatoPHP and the roadmap is dominated by repeated CRUD admin surfaces; weak if entities are non-CRUD or UX is a differentiator. For simple cases, keep native make:model -mfsc rather than reaching for a dependency.
• Cost of adoption: integration time is an afternoon; integration certainty is not. There is no published command reference, so the real API surface has to be discovered from src/Console and src/Generators. Budget for reading generated output line by line and for an ongoing review burden — generated code is a starting point, never a merge without reading.
• Control: publish and commit the config and stubs on day one so defaults cannot drift silently on upgrade. Pin to ^1.0, verify PHP/Laravel/Filament constraints in composer.json first, and diff v1.0.0...v1.0.1 in src/ ourselves since the release notes document nothing. Generate into a scratch namespace (App\Models\Generated) and treat the tool as additive-only — never regenerate models that already carry hand-written casts, accessors, scopes, or traits.
• Policy before rollout, in writing: pick one rule — either "generated files are read-only; customization lives in traits or subclasses" or "generator output is a one-time bootstrap." Ambiguity here is what turns a productivity tool into a merge-conflict generator.
• Exit path: output is plain Laravel, so there is no lock-in — we can drop the package and keep the files. Saying this explicitly in the approval memo converts vendor risk from an open objection into a bounded one.
• Ask: a 1–2 day spike against one representative schema with deliberately awkward features (foreign keys, a non-standard or composite key, custom column types), measured against the hand-built baseline, plus the generation command documented in onboarding before we standardize.