Nova Version Card Laravel Package

Product Decisions This Supports

• Release verification / deployment confidence. A Nova card that surfaces the running application version (and related metadata) in the admin panel turns "which build is actually live in staging vs. production?" from a Slack thread into a glance. This directly supports go/no-go decisions on release day and shortens the loop when a hotfix appears not to have landed.
• Incident triage and support hygiene. During a bug report, support and engineering can confirm the customer's deployed version before reproducing. That reduces misdiagnosis and wasted escalation cycles — a small but real reduction in mean time to triage.
• Build vs. buy: buy (and barely). This is a single-purpose Nova card in the 0.x range. The honest comparison is not "buy vs. build a competitor" but "install this vs. spend half a day writing a custom card." Neither option is strategic; the decision is reversible in an afternoon.
• Roadmap signal, not a roadmap item. The package does not enable new product capabilities. Treat it as internal tooling/developer-experience spend, not as a customer-facing feature to sequence against revenue work.
• Ecosystem fit check for Laravel Nova. If the team standardises on Nova for back-office tooling, a version card is a cheap credibility win for the internal admin surface; if the team is on Filament, or has no admin panel, this package has no product relevance at all.

Release-specific note (v0.1.2): this is a routine patch. The changelog shows a single change to VersionController.php plus a first-time contributor. No new features, no deprecations, no breaking changes, no migration steps. It does not change the product calculus above — but it is a mild positive signal that the package is receiving outside contributions rather than being abandoned.

When to Consider This Package

Consider it when all of the following hold:

• The application runs Laravel Nova (this is Nova-specific; it is not a general Laravel package).
• There is a real, recurring confusion about which version is deployed — multiple environments, frequent deploys, or non-engineers (support, QA, CS) who need the answer without asking an engineer.
• The team already exposes version metadata in the app (e.g. via config/app.php, a build stamp, or a CI-injected env var) for the card to read.
• You accept 0.x semantics: no stability guarantee, API may change between minor versions, and the changelog is terse enough that you should read the diff before bumping.

Look elsewhere (or just write a 30-line custom card) when:

• You are pre-1.0 averse. At v0.1.2, with a small maintainer base and one recent outside contribution, this is not a dependency to put on a critical path. Pin the exact version and vendor-review upgrades.
• You are not on Nova, or your admin surface is Filament, custom Blade, or a separate ops dashboard — the package simply will not apply.
• You need richer release intelligence — changelog rendering, deploy history, health checks, commit SHA plus branch plus build time. This card is a display widget; a real deployment-observability tool is a different (and larger) purchase.
• Your supply-chain policy forbids low-maturity third-party packages in the admin panel. In that case, fork it, or copy the pattern into an internal card you own.

How to Pitch It (Stakeholders)

To executives (one line): A small internal admin widget that shows which version of the product is live, so release verification and support triage stop depending on someone remembering to ask an engineer. Cost is negligible; the decision is reversible.

To engineering: Low-risk, single-purpose Nova card. It is 0.x and lightly maintained, so pin the version, read the diff before upgrades, and cap the blast radius by keeping it strictly inside the Nova admin panel — never in a customer-facing path. If you would rather not carry the dependency, the same outcome is a small custom card reading your existing build stamp; the package is a convenience, not a capability.

What we are explicitly not claiming: this does not unlock features, does not move a product metric, and should not compete for roadmap capacity. It is developer-experience and operational hygiene — worth a slot in an admin-tooling tidy-up, not worth a planning cycle of its own. v0.1.2 itself is a maintenance patch with no user-visible behaviour promised in the notes; treat it as routine and re-evaluate the package if it stays at 0.x with infrequent, thinly-described releases.