Tomato Api Laravel Package

Product Decisions This Supports

• Build vs. buy for CRUD boilerplate — the actual decision on the table. This package doesn't really pose "should we add a dependency?" It poses "do we hand-write the same five endpoints for every model, or template them?" On a roadmap with many conventional resources, that changes cost from days-per-model to hours-per-model. That's a delivery-velocity lever worth a PM's attention; it is not a code-style preference to be settled in a review comment.

• Scoping the API surface into "ship now" vs. "invest later." The honest fit is internal tooling, admin/back-office integrations, and MVP backends. It is not a candidate for customer-facing, regulated, or high-traffic public APIs without hardening the generator does not provide. That framing lets you decide what to expose internally this quarter and what needs a genuine API-product investment — OpenAPI contracts, versioning policy, SDKs — as a separate line item with its own budget.

• Adopt-vs-fork, framed correctly. Zero stars, zero dependents, MIT license, no release since March 2023. The real call is "reference implementation or fork-and-own starting point," not "supported upstream dependency." Because the value lives in the templates rather than the runtime, you can extract the patterns even where you'd never take the package into production. That decouples adoption risk from runtime risk and keeps the option alive cheaply.

• An architectural commitment, whether you intend one or not. Generating code presumes the repository pattern. That's a team-wide standards decision with downstream consequences for testability, onboarding, code review, and how every future contributor writes data access. It should be a tech-lead-owned call made deliberately — not something that arrives as a byproduct of a two-day spike.

• Ecosystem exposure as a portfolio question. The package belongs to the TomatoPHP family (admin panel, Filament tooling). Its value is largely derivative of whether that stack is already in your architecture. Standalone, it's a CRUD scaffolder with no community behind it. Knowing which of those two situations you're in changes the answer entirely.

• Roadmap sequencing under a scale trigger. Ten resources is manageable with one owner and a review checklist. Fifty resources of hand-patched generated code is a de facto internal framework nobody designed. If the roadmap implies a large CRUD surface, force the build-vs-fork call early, rather than discovering the need at resource thirty when migration cost is highest.

• Risk budgeting for the evaluation itself. The decision can be bought for two to three developer-days: a half-day constraint spike, then a one-to-two-day single-model proof. That's a small enough ask to approve without a steering committee, and large enough to produce a real answer. Frame it as purchasing information, not committing to an investment.

When to Consider This Package

Consider it when:

• You're on Laravel and already inside — or actively evaluating — the TomatoPHP ecosystem, where shared conventions cut integration friction rather than add it.
• You have a large, repetitive set of models needing near-identical CRUD endpoints. Payoff scales with model count, not product complexity.
• You're prepared to own the code: fork it, pin the version, name an internal owner, and accept that your team is the maintainer of record.
• The repository pattern is already your house style, so generated output matches convention instead of fighting it.
• The workload is internal, low-blast-radius, and speed matters more than long-term support guarantees.

Look elsewhere when:

• Maintenance risk is disqualifying. Zero stars, zero dependents, no release since March 2023 — no observable community to catch regressions, no evidence of Laravel 11/12 compatibility, no visible security-response process. On production-critical paths, that's close to a hard no.
• You need a real API product: OpenAPI/Swagger contracts, a versioning strategy, pagination and filtering standards, typed client SDKs. A generator ships endpoints; an API product is a different deliverable with a different owner.
• Your API is public-facing or regulated. Generated endpoints still need authn/authz review, input validation hardening, rate limiting, and audit logging. The generator relocates that work — it does not remove it — and it relocates it per resource, which is exactly the wrong shape for compliance review.
• Your team doesn't use the repository pattern. The abstraction becomes pure indirection and a permanent maintenance tax with no offsetting benefit.
• You need vendor support, SLAs, or a documented upgrade path. None exist, and none are likely to appear.

Evaluation gate before any commitment: a half-day constraint spike (does it resolve and boot on your Laravel/PHP version?), then a one-to-two-day single-model proof measuring how much generated output you keep versus rewrite. Pre-agree the stop rule: rewrite more than roughly a third and the generator is saving you nothing. Total downside exposure before a real decision is two to three developer-days.

How to Pitch It (Stakeholders)

To executives: This is a small, MIT-licensed Laravel scaffolding tool that auto-generates standard API endpoints, so engineers don't hand-write the same boilerplate for every data model. The upside is developer velocity on internal tools and back-office integrations — potentially a step-change in cost-per-endpoint when we have many similar resources on the roadmap. The downside is contained: it's free, the license is permissive, and we can evaluate it for two to three engineer-days with a pre-agreed exit criterion. It is not a foundation for customer-facing or regulated APIs, and we would not take on an unsupported dependency — we'd extract the templates or fork them and own the result. The decision I'm asking for today is not "adopt this package"; it's "fund a short evaluation so we can decide with data instead of opinion."

To engineering: Treat this as a scaffold-and-extract tool, not a runtime dependency. The durable workflow is generate → review the diff → harden → optionally drop it from require; the emitted code stands alone. It presumes the repository pattern, so if that isn't our house style, this becomes indirection we pay for forever — that's a standards call for the tech lead, not a side effect of a spike. Three things will bite us if we're careless: generated endpoints almost certainly ship without authorization, mass assignment is on us to review field by field, and regeneration overwrites hand edits — so pick one strategy (generate once and own the output, or harden the published stubs) and stick to it consistently. The highest-leverage move is customizing the stubs once, after the first resource proves out, so every subsequent resource inherits authorization, fillable guards, stable pagination, and rate limiting. Budget one integration test per generated resource immediately — roughly forty lines, and the only thing that will tell us a regeneration broke something. Pin the version, record in the README who owns the generated code, and say out loud that "we use this package" is operationally identical to "we maintain a fork of it." Finally: timebox to one or two days on one boring, non-critical model, and hold the stop rule — if we're rewriting more than a third of the output to match our conventions, we walk away. That's a cheap, legitimate outcome, and agreeing to it up front is what stops us rationalizing our way past a bad result.