Laravel Settings Laravel Package

Product Decisions This Supports

• Build vs. buy for application configuration: A DB-backed settings layer is a recurring "we need an admin panel to change this without a deploy" request. Adopting a package instead of writing bespoke key/value CRUD shifts weeks of engineering into a dependency, freeing roadmap capacity for differentiating work.
• Roadmap enablement for admin-configurable product surfaces: Feature toggles, tenant-level defaults, branding/white-label text, notification thresholds, and per-plan limits all sit on the same primitive. This package becomes the substrate for a class of roadmap items rather than a single feature.
• Multi-tenant and enterprise-tier decisions: Settings scoping is the gating technical question behind "can we sell a configurable enterprise tier?" A package that handles this out of the box de-risks pricing and packaging conversations.
• v1.2.0 specifically — architecture and platform decisions: The configurable Setting model class means the settings model can be rebound to a domain-owned class. For a PM this is an argument that adopting the package does not lock the product into a vendor's data model, which makes it viable for teams planning (or already running) a modular monolith or DDD-style bounded contexts, and reduces the future cost of carving out a separate domain/service.
• Sequencing signal: This release is additive and non-breaking (no migration or data-model requirement stated), so it can be taken opportunistically on a routine dependency bump rather than needing its own roadmap slot.

When to Consider This Package

Consider it when:

• The product is a Laravel/PHP application and the team already accepts Eloquent-backed persistence and the framework's config/cache conventions.
• You need runtime-editable, database-persisted settings — values a non-engineer changes without a deploy — as opposed to static, environment-driven configuration.
• Multi-tenancy or per-scope overrides are on the roadmap; you want scoping solved once rather than reinvented per feature.
• Typed values (booleans, arrays, numbers) matter, so call sites aren't littered with stringly-typed casts.
• Your architecture is heading toward domain separation, where the v1.2.0 configurable model class lets each bounded context own its own settings entity, table, and validation rules — with the package supplying the resolution, caching, and retrieval mechanics.
• You want an escape hatch: a swappable model means you can extend or replace behaviour without forking the package.

Look elsewhere when:

• You need a full feature-flag platform — percentage rollouts, experiment assignment, audit trails, a hosted UI, SDKs across services. That's a different product category; this is a persistence primitive, not a flagging service.
• You need per-user preference UI semantics at scale (paginated user lists, bulk edits, GDPR export/erase per preference). The storage may fit, but the product surface and tooling won't.
• Compliance or audit requirements are strict — regulated change history, approval workflows, or immutable config logs need to be designed deliberately, not inherited.
• The stack is not Laravel, or the team is deliberately framework-agnostic in the domain layer.
• Configuration is genuinely static and deploy-coupled; adding a DB round-trip and a caching layer buys nothing.

How to Pitch It (Stakeholders)

For executives: This is a small, low-risk dependency that removes a recurring engineering chore — building and maintaining an internal "change settings without a deploy" system. It shortens the path to admin-configurable features (plan limits, white-labeling, operational thresholds) that sales and support keep asking for, and it does so without committing us to a vendor's data model. The latest release makes the settings model replaceable, which protects us if we later reorganise the codebase or split out a service. Recommendation: adopt on the next suitable work item, treat as infrastructure, no dedicated roadmap slot required.

For engineering: Thin adoption surface — the package provides the settings store, retrieval API, casting, and caching; the application keeps ownership of the schema and the domain rules. The v1.2.0 configurable model class is the important detail: bind the Setting model to a domain-owned class so each bounded context can carry its own table, casts, and validation, keeping the settings concern out of the shared kernel. It is backward compatible, so the upgrade is a composer bump plus, optionally, a refactor to point at a domain model. Please add a smoke test covering the rebound model and the cache-invalidation path before rollout, and confirm our intended scoping strategy (global vs. tenant vs. user) in the ADR so the decision is explicit rather than inferred from defaults.