Tomato Saas Laravel Package

Technical Evaluation

What the release actually tells us. v1.1.4 ships with no changelog body — only an autogenerated compare link (v1.1.3...v1.1.4). From a release-management standpoint that is a zero-signal release: we cannot tell whether it is a one-line dependency bump, a migration change, or a quiet breaking change to a published config file. Semantic versioning implies patch = safe, but patch-level discipline is not something this vendor has demonstrated to us, and small-team Laravel packages routinely ship schema or config changes under a patch number. This assessment is therefore a baseline orientation, not a verdict on v1.1.4 specifically, and it should be treated as provisional until the diff is read.

Architecture fit. tomato-saas is a Tomatophp SaaS scaffolding package for Laravel: plans/subscriptions, tenant-or-team modelling, billing hooks, and a Filament-based admin surface, distributed as a Composer package with publishable config and migrations. Fit is bimodal:

• Greenfield SaaS on Laravel + Filament — high fit. It collapses several weeks of subscription/plan/tenant plumbing into an install.
• Existing product retrofitting billing or tenancy — low-to-medium fit. Packages of this class tend to assume ownership of the users/teams shape and the panel's navigation and auth flow. Retrofitting means either bending your schema to theirs or maintaining a fork.

Integration feasibility. Mechanically easy (composer require, publish config/assets, run migrations, register the Filament plugin). The cost is not installation, it is convergence: deciding whether the package's opinion about tenants, roles, and plan gating matches yours, and what happens at the boundary when it doesn't. Budget the evaluation time against the domain model, not the install.

Technical risk.

• Vendor concentration — Tomatophp is a small, prolific package shop. Many packages, few maintainers, high release cadence. That is a bus-factor and long-term-support risk, not a code-quality judgement.
• Filament version coupling — the most probable breakage vector. Filament major upgrades (v3→v4) break plugin packages routinely. Any Laravel or Filament upgrade in your app becomes a coordinated upgrade with this dependency.
• Opaque release history — the empty changelog is itself the finding. A package whose releases are unreadable is a package you cannot safely auto-update.
• Schema ownership — published migrations mean your database now carries a third party's assumptions. Reversing that later is expensive.
• Billing correctness — subscription state, proration, and webhook idempotency are money paths. Test coverage in this class of package is usually thin and undocumented.

Key questions to answer before committing.

1. What is the actual diff between v1.1.3 and v1.1.4 — does it touch database/migrations/, config/, or composer constraints?
2. Which Laravel, PHP, and Filament versions are supported, and does the constraint set overlap our target stack?
3. What is the tenancy model — single-DB scoped, multi-DB, or single-tenant-per-install? Does it match ours?
4. Which payment providers are first-class vs. stubbed?
5. Is there CI, a test suite, and what is the coverage on subscription lifecycle and webhooks?
6. License terms and security-disclosure policy — can we fork and patch if the vendor goes quiet?
7. Are migrations reversible, and is there a documented upgrade path between minors?

Integration Approach

Stack fit. Confirm the composer constraints resolve against our Laravel/PHP/Filament versions before any spike. A failed composer require in a throwaway app is a ten-minute answer to a question that otherwise costs a week. Note that this package likely pulls Filament transitively — that makes Filament a coupled dependency across the whole admin surface, which is a significant architectural commitment for an admin-panel decision, not just a SaaS decision.

Reading the release. Treat v1.1.4 as unverified until reviewed. Concretely: clone the repo, git diff v1.1.3 v1.1.4 --stat, then read the diff for migrations, config keys, and public method signatures. This is a 30-minute task and it is the single highest-value action available right now. If the diff is empty or trivial, the risk profile is unchanged and we can adopt at v1.1.4. If it contains a migration or config-key rename, we need a documented upgrade note before anything reaches staging.

Migration path. Adopt at a pinned exact version, never a floating constraint ("tomatophp/tomato-saas": "1.1.4"), with composer.lock committed. Upgrades become deliberate, reviewed events rather than background drift. Budget for a fork: fork the repo into our org, tag our own releases, and pull upstream on our cadence. This costs little and removes the abandonment and opaque-release risks almost entirely.

Compatibility. Run the spike in an isolated branch against a snapshot of the real database, not a fresh one. Fresh-install success tells you nothing about migration behaviour on populated tables. Exercise: install, migrate, seed a plan, create a tenant, run a subscription transition, fire a webhook, roll back. Rollback is the step most evaluations skip and the one that determines how bad a bad upgrade gets.

Sequencing.

1. Constraint check (hours) — does it resolve against our stack?
2. Diff review of v1.1.4 (hours) — is the release safe?
3. Domain-fit spike (3–5 days) — build one real vertical slice (signup → plan select → entitlement check) against a copy of our schema. Do not build a demo in a clean app; that answers the wrong question.
4. Decision gate — adopt, adopt-and-fork, or build in-house. Set explicit criteria before the spike (schema disturbance, upgrade coupling, billing coverage) so the decision isn't vibes.
5. Pilot in one non-critical tenant behind a feature flag, with billing in test mode.
6. Generalise only after a full billing cycle has passed cleanly.

Operational Impact

Maintenance. Ongoing cost is dominated by version coupling, not by the package's own bug rate. Every Laravel, PHP, and Filament upgrade now has a second-order dependency on whether this package has caught up. Assume 2–4 hours per quarter in routine alignment, plus a half-day whenever Filament or Laravel cuts a major. The fork-and-pin strategy converts unpredictable vendor-cadence risk into predictable internal work, which is the right trade for anything on the money path.

Support. Expect GitHub-issues-level support with no SLA. That is acceptable for scaffolding and unacceptable for a billing critical path unless we own the fork. Establish an internal owner — a named engineer or small team — responsible for the fork, upgrade cadence, and security review. An unowned third-party dependency on the revenue path is the failure mode that shows up in postmortems.

Scaling. The package is not the scaling bottleneck. Application-level PHP code for plan lookups and subscription records is trivial next to the real constraints: webhook throughput and idempotency, subscription-state query patterns, and whether entitlement checks are cached or hit the database on every request. Review the entitlement-check path specifically — if it issues a query per feature gate, that is a hot-path problem at scale and worth wrapping in a cache layer early. Multi-tenant data isolation is the other scaling concern; confirm the tenant scoping is enforced at the query layer and cannot be bypassed by a forgotten where.

Failure modes, ranked.

1. Silent schema drift on upgrade — highest severity. Mitigated by pinning, diff review, and a rollback rehearsal on a production-shaped snapshot.
2. Vendor abandonment or stall — medium probability, high impact. Mitigated by the fork and by keeping the integration surface narrow (wrap the package behind our own billing interface rather than calling it directly from controllers and Livewire components).
3. Filament major-version break — periodic, disruptive, predictable. Mitigated by not upgrading Filament and this package in the same release.
4. Billing/webhook regression — silent revenue or entitlement error. Mitigated by reconciliation reporting against the payment provider and alerting on subscription-state divergence, independent of the package's own health.
5. Tenant leakage — a missing scope exposes one customer's data to another. Mitigated by automated cross-tenant access tests, not code review.

Ramp-up. A Laravel developer is productive with the package in 1–2 days; productive safely on the billing path in 1–2 weeks, and that extra time is spent on the billing domain (plan transitions, proration, dunning, webhook replay), not on the package's API. Two things shorten the curve materially: an architecture decision record documenting the integration boundary and the fork policy, and a written runbook for "upgrade this dependency" that includes the diff-review step that this release makes obviously necessary.