Nova Priority Laravel Package

Product Decisions This Supports

• Build vs. buy (early triage): This is a 0.1.0 "First Commit" release — treat it as an evaluation candidate, not a dependency. The only decision it currently supports is whether to spend a spike (½–2 days) proving the package against our Laravel version and one real use case.
• Architecture direction, not commitment: Useful as a reference implementation to inform internal design discussions (e.g., how we'd structure the same capability ourselves) without locking the roadmap to an unproven API surface.
• Roadmap de-risking: If the package addresses a non-differentiating concern (queue plumbing, audit logging, feature flags, etc.), it can be slotted as a "candidate for later adoption" behind an internal interface we control, keeping the swap cost low.
• Use cases it can inform: Internal tooling, admin panels, and low-blast-radius utilities where a pre-1.0 dependency failing is recoverable — not core revenue paths, auth, payments, or anything customer-data-adjacent on day one.
• Explicitly does NOT support: Any commitment to procurement, vendor review, or a production launch decision. With zero release history, there is no evidence of maintenance cadence, security posture, or upgrade behavior.

When to Consider This Package

Adopt for evaluation when:

• We have a specific, already-scoped problem it solves — and we can state the problem in one sentence without naming the package.
• It targets a Laravel/PHP version we actually run, and the repo shows a declared support matrix.
• The dependency tree is small enough that we can audit it in an afternoon.
• The capability is commoditized for us (no competitive differentiation lost by outsourcing it).

Look elsewhere — or build — when:

• The package is pre-1.0 with a single commit and no tagged release history. Semver guarantees are absent; any minor bump may be breaking by definition.
• There is no documented license, no CI status, no test suite, and no named maintainer with a public track record.
• The functionality touches auth, payments, PII handling, or anything requiring an audit trail.
• The maintenance surface would exceed our own: if we'd have to read the source to use it, we've already paid most of the build cost.
• It overlaps something we already run — adding a second library for the same concern is a net negative regardless of quality.

Gate for re-review: Revisit the assessment at 0.2.0 with a changelog, a test suite, and at least one third-party production reference. Until then, pin nothing.

How to Pitch It (Stakeholders)

For executives (one line): A very early Laravel component surfaced as a potential shortcut for a non-core capability — we're running a short, bounded spike to see if it saves engineering time, and no production commitment is being made at version 0.1.0.

For engineering (the real message): This is a first commit — assume the public API will churn and budget for reading the source before trusting it. Run the spike against a throwaway branch, wrap any usage behind our own interface so removal is a one-file change, pin an exact version, and record what would have to be true at 0.2.0 for us to keep it. The win case is a few days saved on plumbing; the loss case is a day of spike time. Both are acceptable — what isn't acceptable is taking a transitive dependency on a single-commit package in a customer-facing path.