Nova Json Schema Field Laravel Package

Product Decisions This Supports

• Roadmap timing, not feature delivery. This is an initial 1.0.0-RC1 with an explicit "do not use in production" warning from the maintainers. Its only current product value is as a market signal: it tells us a Laravel-native solution for this problem space is emerging, which is relevant if we're currently paying for a SaaS equivalent, maintaining bespoke code, or have a backlog item in this area.
• Build vs. buy vs. wait. The package opens a third option beyond building in-house or buying a vendor product — but it is not yet a viable "buy" (or "adopt"). The decision it supports today is whether to defer a build commitment in anticipation of a stable release, and to set a review checkpoint (e.g., re-evaluate at 1.0.0 GA or after RC bugs are resolved).
• Risk framing for existing plans. If any roadmap item assumed a mature third-party Laravel package existed here, that assumption should be flagged as unvalidated. No estimates should be tightened on the strength of an RC.
• Not a use-case enabler yet. No production use cases should be scoped against this package. Prototype/spike work only, and only if the team has slack capacity and a concrete question the spike would answer.

When to Consider This Package

Consider it (for evaluation only) when:

• The problem it addresses is on your roadmap or already costing money via a commercial alternative.
• You have engineering bandwidth for a throwaway spike, and a specific question a spike would answer (API ergonomics, fit with your Laravel version and conventions, migration cost off the incumbent).
• You can accept that the public API will likely change before GA, and that packaging defects are expected and disclosed.

Look elsewhere — or wait — when:

• Any part of the work touches production, customer data, or a compliance-sensitive path. The maintainer's own warning is disqualifying here; treat "expect packaging bugs" as a hard stop.
• You need stable public APIs, documented upgrade paths, semantic-versioning guarantees, or a security disclosure policy. None of these can exist meaningfully at RC1.
• You need support SLAs, a maintainer track record, or evidence of production adoption at scale.
• Your team cannot absorb churn. Adopting an RC into a committed roadmap converts the maintainer's packaging risk into your delivery risk.
• A mature, maintained alternative already satisfies the requirement — an RC should not displace a working solution on novelty alone.

Required due diligence before any promotion past evaluation: confirm Laravel/PHP version support and test matrix, review the issue tracker for packaging-defect volume and maintainer responsiveness, verify license compatibility, check whether CI and static analysis are configured, and identify whether the maintainer is an individual or a team (bus-factor risk). Set an explicit re-review trigger — GA release, or a stated stabilization milestone.

How to Pitch It (Stakeholders)

To executives: A promising Laravel-native package for [problem space] has published its first release candidate. It is explicitly not production-ready — the maintainers warn of packaging defects and advise against production use. We are not recommending adoption. We are recommending we track it and revisit at general availability, because if it stabilizes it could replace [current cost/vendor/bespoke maintenance] and reduce our dependency on an external service. No budget, headcount, or timeline change is requested now. The decision on the table is a deferred one, with a named review point.

To engineering: Treat 1.0.0-RC1 as pre-alpha in practice. No production dependencies, no scoping work against its API. If someone has spare cycles, a time-boxed spike against a non-critical surface is acceptable to assess fit and ergonomics — with the expectation that findings may be invalidated by GA. Report back on: API stability signals, packaging quality, and whether it clears our dependency-adoption bar. Flag immediately if any existing roadmap item was quietly assuming this package was usable.