Nova Welcome Card Laravel Package

Product Decisions This Supports

• Admin onboarding and in-product guidance: The default Nova "Help card" is static; this package makes the content configurable, so PMs can decide what guidance admins see (docs links, support channels, release notes, internal process reminders) without a code change to Nova's core.
• Support deflection vs. live support: A concrete lever in the "reduce inbound support tickets" vs. "staff a help desk" trade-off. If a configured card can surface the top five runbooks, that's measurable deflection at near-zero cost.
• Build vs. buy (buy vs. build vs. skip): The scope is small enough to replicate in-house in a few hours. The PM decision is whether a 5-star, zero-dependent MIT package is cheaper to adopt than a bespoke Nova card — including the cost of vendoring or forking it.
• Admin UX roadmap prioritization: Signals whether "polish the internal admin panel" is worth a slot on the roadmap. Low-effort wins like this are often sequenced ahead of larger admin redesigns.
• Standardizing internal tooling: If multiple Laravel Nova deployments exist across teams, a shared configurable card is a lightweight way to enforce a consistent help/support entry point.
• Announcement and change-management surface: The card can carry release notes or deprecation warnings, supporting rollout comms for internal or customer-facing admin users.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova — this is useless outside that context, and Nova itself is a paid product, so the addressable audience is narrow by definition.
• You need to change the help card's content frequently (docs links, support contacts, onboarding copy) and want that to be configuration rather than a patch to Nova internals.
• You want a fast, reversible experiment: MIT licensed, single-purpose, easy to remove or fork.
• Your team is comfortable owning a small dependency — with 5 stars and 0 dependents, treat it as unmaintained-by-default and plan to vendor or fork it.
• You accept low blast radius: if it breaks, the failure mode is a cosmetic card in the admin panel, not core functionality.

Look elsewhere when:

• You are not on Nova, or you use a different admin stack (Filament, Jetstream, custom dashboards).
• You need real onboarding tours, tooltips, checklists, or analytics — that's Intercom, Pendo, Appcues, or a purpose-built in-app guidance tool, not a card.
• You require vendor SLAs, security review provenance, or long-term maintenance guarantees — a solo-maintained package with near-zero adoption will not clear procurement.
• You need multi-tenant or per-role content logic beyond basic configuration — you'll be writing that yourself anyway.
• The requirement is substantial enough to justify building: at this scope, a custom Nova card is a defensible alternative and removes the dependency entirely.

How to Pitch It (Stakeholders)

For executives: This is a small, low-cost enhancement to our Laravel admin panel. It lets us control the help card admins see — pointing them to documentation, support channels, and release notes — which is a cheap way to reduce inbound support load and speed up internal onboarding. It's MIT licensed, costs nothing, and is trivially reversible. It is not a platform bet: adoption is negligible and the package is effectively self-maintained, so we should budget a few engineering hours to fork and own it rather than depend on upstream. Expected upside is modest and measurable (support ticket volume, time-to-first-task for new admins); downside is a cosmetic admin card breaking.

For engineering: A thin, configurable replacement for Nova's built-in Help card. Single-purpose, MIT, small surface area. Recommend vendoring or forking into our codebase so we control upgrades and aren't exposed to a low-activity upstream. Integration is configuration-level, not architectural — no data model or API impact. Fallback is a bespoke Nova card, which is a few hours of work if the package misbehaves.