Nova Simple Repeatable Laravel Package

Product Decisions This Supports

• Shipping editorial admin features without a schema project. This field turns any Laravel Nova resource into a repeatable-rows editor — FAQ blocks, spec tables, contact lists, pricing tiers, link groups, metadata pairs — persisted as JSON on the parent model. A PM can greenlight content-editing capabilities that would otherwise need a child table, a related resource, relationship management, policies, and a migration plan. It collapses that workstream into a column, a cast, and a field definition.
• Build vs. buy for admin form fields. The alternative is bespoke Nova field development: a Vue component, JSON casting, validation plumbing, and ongoing maintenance against future Nova majors. MIT licensing plus a narrow, well-understood scope makes adoption cheaper than ownership for this recurring pattern. Adopt, don't build — unless requirements outgrow "repeatable group of small inputs."
• Roadmap sequencing and deliberate deferral. It lets the team ship an editable admin experience now and postpone normalized modeling until reporting, per-row permissions, audit history, or workflow needs actually materialize. Treat this as a named deferral with an explicit trigger for migration, not a permanent data-modeling strategy. Write the trigger down in the ticket.
• Scope control as a product decision. The package quietly encourages bounded, document-shaped data. The PM's job is to keep it that way: cap rows and sub-fields, declare the JSON column off-limits for analytics, and refuse requests that push complex domain relationships into a blob. When the product genuinely needs joins or per-row authorization, the correct decision is a child table, not this field.
• Vendor and operational decisions. 75 stars, 0 dependents, a single maintainer, no SLA, and a recent 3.0.1 with ->stacked() added. That's a tactical-adoption signal, not a platform-standard signal. Adopting it means pinning the version, naming an owner, and budgeting upgrade testing alongside the Nova license renewal.
• Discovery and validation sequencing. Best used as a pilot on one low-risk, read-mostly resource to measure admin build time saved, editorial usability, and validation gaps before promoting it to a team convention.

When to Consider This Package

Consider it when:

• The product already runs Laravel Nova and the license is budgeted and renewed. This is a gate, not an assumption — without Nova, the package is not a candidate at all.
• The data is simple, bounded, and editorial: an array of small objects with a stable-ish shape, stored in one json/text column.
• The team accepts the JSON-column tradeoffs: no database-level constraints, shape enforcement living in PHP, weaker query and reporting flexibility than normalized tables, and application-level validation required for any non-Nova writer (seeders, imports, APIs).
• Speed beats perfect modeling, and no near-term requirement exists for per-row authorization, joins, aggregation, audit trails, or BI.
• Engineering can pin the version, smoke-test Nova upgrades, and fork under MIT if the maintainer goes quiet.
• Row and sub-field counts stay inside a UI and request budget — the component renders every row, so unbounded payloads hurt form load and save time.

Look elsewhere when:

• The product is not on Nova, or the Nova license cost/renewal is itself an open decision.
• Data needs relationships, joins, aggregation, audit history, or per-row permissions — use a normalized child model.
• Requirements include deep nesting, complex conditional logic, or heavy validation beyond a simple repeatable group.
• The organization requires high adoption, commercial support, or a broad contributor base for admin infrastructure.
• You need to filter, sort, or report on nested values in the hot path — plan to denormalize into indexed columns or a search index instead.
• The team cannot absorb two-vendor upgrade risk (Nova's release cadence plus this package's) or the cost of maintaining a fork.

How to Pitch It (Stakeholders)

Executive summary: A small, MIT-licensed Laravel Nova field that lets editors add repeatable rows of structured inputs inside an admin form, stored as JSON on a single record. It removes custom development for common content-editing patterns — FAQ lists, spec tables, pricing tiers — ships faster, costs nothing to license, and has a limited blast radius because the code is forkable and confined to the admin layer.

Engineering summary: Adopt it as a tactical Nova form-field dependency, not a core platform commitment. It fits simple JSON-backed editorial data and avoids premature relational modeling. The real cost isn't installation (composer require, add a nullable column, cast it, declare nested fields) — it's the contract: the JSON shape lives in PHP field definitions, isn't database-enforced, and must be mirrored in API resources, exports, seeders, and reporting. Mitigate with a single DTO/cast as the canonical shape owner, application-level validation for non-Nova writers, a hard row cap, version pinning against the Nova major, and a staged upgrade smoke test. MIT means forking remains the contingency.

Recommendation: Pilot on one low-risk, read-mostly Nova resource — not core transactional data. Measure implementation time saved, editorial usability, and validation gaps, and watch form load/save time at realistic row counts. Promote to a team standard only if the pattern recurs and the package holds through your upgrade cycle; otherwise treat it as a one-off and capture the exit path (fork, alternative field package, or normalized table) before it spreads.