Tomato Settings Module Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-configurable settings. The recurring "we need a settings screen" request is almost never a differentiator. This package lets you buy/borrow that surface (typed, grouped, persisted settings with a Filament admin UI) instead of spending a sprint of engineering time on a CRUD table plus its cache invalidation, validation, and permissions plumbing.
• Roadmap: shift configuration from deploy-time to runtime. Concretely this unlocks shipping features where a non-technical admin can change mail/SMTP credentials, branding and logos, currency/timezone/locale defaults, third-party API keys, feature flags, and module toggles — without a deploy or a developer. That is a roadmap capability (self-serve operations), not just a UI convenience.
• Support-ticket reduction. A large share of routine ops requests ("change the sender address", "turn off the maintenance banner", "update the payment key") collapse into self-service edits. This is one of the cheapest measurable wins you can put in a quarterly plan.
• Faster delivery of the admin panel itself. If Filament is already the admin stack, this is close to zero-marginal-cost vertical integration: it inherits your auth, your panel, and your resource conventions instead of introducing a second admin paradigm.
• Enables feature-flagging and staged rollout. Once settings are runtime-mutable and cached, you get a lightweight flag store for canary releases and per-environment behavior without standing up LaunchDarkly-class tooling.
• Low-regret decision. The scope is bounded and the integration surface is small, so this is a reversible call — appropriate for a spike, a pilot, or an internal tool, and easy to unwind if it disappoints.

When to Consider This Package

Adopt when:

• You are on Laravel + Filament (TomatoPHP ecosystem or willing to add it), and the settings screen would otherwise be hand-rolled.
• You need grouped, typed, validated, runtime-editable settings with caching — not env-var-only configuration.
• You want settings editable by non-engineers through an existing admin panel, with the usual Filament authorization/model policies doing the access control.
• You are building internal tools, MVPs, or agency/client projects where time-to-first-value dominates and a long-term vendor SLA is not required.
• You want a single, conventional place for configuration so that "where does this value live?" has one answer.

Look elsewhere when:

• You are not on Filament. The value here is largely the UI; without Filament you are carrying a dependency for a table you could own in ~200 lines. spatie/laravel-settings (typed settings classes, no UI) is the more neutral choice.
• You need strict per-tenant isolation of settings with auditable override semantics; multi-tenant config is a different problem than "an app settings table" and needs explicit design.
• You need compliance-grade audit trails (who changed which secret, when, approved by whom) or secret storage in a vault (AWS Secrets Manager, Vault, Doppler). Settings UIs are a common accidental path to credentials landing in a plaintext DB column; verify encryption-at-rest for sensitive keys before committing.
• You require a supported vendor, SLA, or long-term maintenance guarantee. A young package in a single-maintainer ecosystem is a real continuity risk — mitigate with an abstraction layer or accept the risk knowingly.
• Your configuration is genuinely static. If nothing ever needs to change without a deploy, a settings module is pure added surface area.
• Maturity matters more than speed. v1.0.0 is the first stable tag with a thin release note (a changelog link only). Treat the semver commitment as intent, not evidence: confirm the 0.x → 1.0 upgrade path, Filament version compatibility, and test coverage in a spike before it becomes load-bearing.

How to Pitch It (Stakeholders)

To executives (one paragraph): This is a small, low-cost component that lets the people who run the product change its behavior — pricing display, email sender, branding, integrations, feature toggles — without filing an engineering ticket. It converts recurring operational requests into self-service, shortens the loop between a business decision and it being live, and costs us days rather than the sprint we would spend building and maintaining the equivalent screen. It is contained enough to pilot on one surface and reverse if it does not earn its place.

To engineering (one paragraph): It is a Filament-based settings module for Laravel: a migration-backed, grouped and typed settings store with a ready-made admin resource, so we stop re-implementing the same config CRUD on every project. It follows framework conventions, plugs into our existing panel and policies, and is cache-friendly. The ask is a timeboxed spike: verify the 1.0 upgrade path, Filament compatibility, and how sensitive values are stored; wrap access behind our own settings contract so the package stays swappable. If the spike is clean, we standardize on it for admin-configurable values and keep env vars for infrastructure secrets only.

Recommended next step: a two-day spike scoped to one non-critical settings group (branding or mail), gated on: encryption handling for sensitive keys, cache invalidation behavior on update, and a documented rollback. Decide adopt / wrap / drop at the end of the spike — not before.