Nova Key Value Laravel Package

Product Decisions This Supports

• Build vs. buy vs. fork (the real decision here). A key-value field is a thin UI wrapper over a JSON/text column — typically a few hundred lines including the Vue component. With 18 stars, a 2019 last release, and an archived repo, nobody is "buying" anything; the actual decision is whether to vendor/fork the source (~1 day of engineering) or move to a maintained alternative. The package's value to a PM is as a reference spec for the admin experience, not as a dependency.
• Schema flexibility vs. schema discipline. Supporting an editable key-value field is a product-level commitment to letting admins define their own data shape at runtime. That buys faster iteration on per-record metadata (product attributes, tenant settings, integration credentials, feature-flag payloads, localized overrides) without a migration per change — and it costs you queryability, validation guarantees, and reporting reliability. This package makes that tradeoff easy to say yes to; a PM should say yes deliberately.
• Roadmap sequencing around the Nova upgrade. Because the package is archived and pinned to the Nova 1.x/2.x era, it effectively forces a roadmap item: either upgrade to Nova 4+, where a built-in KeyValue field ships in core, or migrate to a maintained community field, or freeze the Nova version. Any of those is a scoped, plannable piece of work — the unacceptable outcome is drift where the field silently rots with no owner.
• Whether free-form JSON blobs are a supported product surface. The package makes "admins can edit arbitrary structured data" a first-class, discoverable capability. That's a governance question (who can write? is it validated? is it exported/backed up? is it in the audit trail?) that a PM should answer before shipping it, not after.
• Sunset/deprecation decisions. Archived dependency is a standing liability: no security patches, no Nova compatibility guarantees, no upstream for bug reports. Tracking it in the dependency register and deciding "replace by " is exactly the kind of low-glamour, high-value call a PM can force.

When to Consider This Package

Consider it when all of the following hold:

• You are on Nova 1.x or 2.x and have no near-term upgrade path.
• You need a small set of flat, string-keyed, scalar-ish key-value pairs editable in the admin — not nested objects, not typed schemas.
• You are comfortable vendoring or forking the source into your own namespace and owning it, treating the GitHub repo as a starting point only.
• Your team accepts that validation, authorization granularity, and audit logging are your responsibility to add.

Look elsewhere — or don't adopt — when:

• You are on Nova 4 or later: use the built-in Laravel\Nova\Fields\KeyValue. Adopting a third-party archived field over a core field is strictly downside.
• You need a maintained community field. Several actively maintained Nova key-value packages exist; verify current Nova-version compatibility, release cadence, and open-issue health before committing.
• Your data actually has a known schema (typed attributes, enums, references). A key-value editor is the wrong tool — it defers schema decisions to whoever is at the keyboard, and you will pay for it in reporting and data quality.
• You need nested structures, per-key validation, ordering, translations, or role-scoped edit rights. This package does not offer them.
• You are not on Nova at all, or you're evaluating Nova itself. This is not an argument for or against the platform.

How to Pitch It (Stakeholders)

To executives (30 seconds): This is a small, unmaintained admin-UI add-on that lets staff edit free-form settings on records without engineering involvement. It is not a strategic dependency and we should not build a roadmap on top of it. Recommendation: treat it as a template, not a vendor — either adopt the equivalent capability that now ships natively in our admin framework, or vendor the ~few-hundred lines and own them. Either path is roughly one engineering day and removes an unsupported third-party code path from our stack. The only real cost of inaction is a silently unmaintained field with no security patch path.

To engineering (the ask): Confirm three things before we close this out — (1) which Nova version we're targeting, since Nova 4+ has a native KeyValue field that likely obsoletes this entirely; (2) if we still need it, whether we fork it into our namespace with a named owner and a pinned version; (3) whether we add validation and an audit trail on writes, because the package gives us none. Also flag the data-model consequence: anything stored in this field is not individually indexable or type-safe, so we should agree up front on what is and isn't allowed in it.