Nova Settings Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-editable settings. This package replaces a recurring build task — "we need a screen for marketing to edit X" — with a config file and a Nova tool. For a PM, that is a schedule compression play: hours instead of a sprint, and no bespoke admin UI to maintain.
• Feature scoping and roadmap sequencing. Content-heavy or operational values (support email, promo banner copy, default currency, onboarding copy, third-party API keys, per-locale strings) can ship as settings rather than code, so the roadmap item becomes "make it editable" instead of "build a CMS."
• De-risking launch dependencies. Anything that would otherwise require a deploy to change — pricing copy, legal disclaimers, integration toggles, timezone/locale defaults — can be handed to ops or support on day one, reducing the "wait for the next release" bottleneck.
• Internal-tool leverage for existing Nova customers. If Nova is already the back office, this is a near-zero-marginal-cost addition to the admin surface, useful for B2B products where a small ops team manages configuration for many customers manually.
• Deliberately not a feature-flag or config-management platform. It stores editable values, not rollout logic, targeting rules, audit trails, or secrets. Treat it as an "ops-editable content/parameters table with a native-field UI," and scope roadmap bets accordingly.

When to Consider This Package

Adopt when all of these hold:

• The product already runs Laravel Nova — this package is worthless without it, and Nova itself is a per-site paid license, so the true cost is Nova + maintenance, not $0.
• The settings are few, global, and human-edited (roughly dozens, not thousands), and fit native Nova field types: text, textarea, boolean, select, image/file, date.
• Non-developers (ops, marketing, support) need to change values without a deploy.
• The team accepts the maintenance and bus-factor risk: a single-agency package, moderately small audience, and low dependent count — assume you may need to fork or vendor it.

Look elsewhere when:

• No Nova in the stack. Building an admin panel just to adopt this inverts the cost-benefit; consider Filament plus a settings package, or a plain custom CRUD screen.
• You need typed, validated, cached, environment-aware settings. spatie/laravel-settings with typed setting classes and migrations is the stronger architectural fit; this package is thinner on validation and typing.
• You need multi-tenancy, per-user, or per-team scoping. Global key-value storage will not carry this without custom work.
• You need audit history, approvals, rollback, or change attribution. Not provided; if compliance or "who changed the price?" matters, build on top or buy a config service.
• You need secrets. API keys edited in a UI are a security review item; prefer a secrets manager or environment configuration.
• You need runtime flags with targeting/experimentation. Use Laravel Pennant or a dedicated flag service instead.
• Read path is hot. Values live in the database; confirm caching behavior before putting settings on a per-request critical path.

How to Pitch It (Stakeholders)

For executives: A small, MIT-licensed Laravel Nova add-on that turns "engineering must deploy to change a value" into "operations edits it in the admin panel." It removes a class of low-value tickets and unblocks marketing/support changes from the release train. Cost is effectively zero in license terms, but it presumes we already pay for Nova and it carries single-maintainer risk — so treat it as an internal convenience tool, not infrastructure, and keep a fallback.

For engineering: It's a thin Nova tool that renders native Nova fields and persists values to a settings table, exposed through an accessor helper. Low integration cost, no new runtime dependencies beyond Nova, MIT licensed. Constraints to plan around: global scope only, limited typing/validation, no audit trail, DB-backed reads (verify caching), and a small maintainer base — we should pin the version, wrap access behind our own helper, and be ready to vendor it if releases stall.