Preferences Module Laravel Package

Product Decisions This Supports

• Build vs. buy for preference/settings infrastructure. This module supplies the persistence layer, control-panel surface, and module conventions for storing user- and application-level preferences. If we are already on the Streams Platform, adopting it removes a recurring "we need a settings screen" build from the backlog.
• Release scoping. Per-user preferences, namespaced configuration, and admin-editable defaults are usually table stakes for a v1 of any multi-user product. This package lets us treat them as configuration rather than as a feature we must design, estimate, and QA.
• Platform strategy. The module's existence lowers the marginal cost of staying inside the Streams/PyroCMS ecosystem instead of migrating to a plain Laravel stack, because a standard capability is provided for free under MIT.
• Concrete use cases: per-user display/UI preferences, tenant or site-level configuration, module-level defaults with user overrides, and lightweight feature toggles that need an admin-facing editor.
• Roadmap input. It informs whether we invest engineering time in differentiated product surface (recommended) or in undifferentiated settings plumbing (avoid).

When to Consider This Package

Adopt it when all of the following hold:

• We are already running the Streams Platform (or PyroCMS/Anomaly-based stack) and need preference management that matches its addon, migration, and control-panel conventions.
• We want the capability to arrive as a normal module so core upgrades and other addons stay aligned, rather than introducing a parallel settings subsystem.
• We accept that we are consuming a vendor-supplied component, not a community package, and are prepared to own upgrades, security review, and patching ourselves.

Look elsewhere when:

• The application is standalone Laravel. Mature alternatives (spatie/laravel-settings, config-backed approaches, or a simple typed JSON column) carry far more external validation and less ecosystem coupling.
• We need high-volume, strongly typed, or schema-validated configuration, or configuration that must be read on hot paths without platform overhead.
• We require active community support, published issue history, or third-party production evidence. With 0 stars and 0 dependents there is no external validation signal — treat it as a first-party internal dependency with a maintenance obligation, not a battle-tested open-source pick.
• We are not prepared for lock-in to a single-vendor ecosystem; exiting later means replacing both the storage and the UI integration.

How to Pitch It (Stakeholders)

To executives: This is not a product; it is a free (MIT), internal building block that removes a small but recurring piece of undifferentiated work from every release — the settings and preferences screens every multi-user product needs. It costs no license fee and shortens time-to-market for preference-related features. The real risk is not money but dependency: it comes from a single vendor with no external adoption, so we should treat it as something we own and maintain.

To engineering: It gives us preference persistence and a control-panel editing surface that already conforms to Streams' module, migration, and namespace conventions, so we avoid writing a parallel settings layer that would fight the platform on every upgrade. Integration is a normal module install; the code is readable and MIT-licensed, so we can fork or patch if upstream stalls. Caveat: no community traction, so we pin the version, review it before adoption, and budget a small maintenance allowance.

Recommendation: Adopt only if we are already committed to the Streams Platform and need preference management within the next one to two releases. Do not introduce it into a standalone Laravel codebase, and do not treat its existence as a reason to choose the platform.