Nova Greeter Laravel Package

Product Decisions This Supports

• Build vs. buy for admin-surface polish. oriondevelops/nova-greeter is best treated as a reference implementation, not a strategic dependency. Its value to the roadmap is proving out the "personalized Nova dashboard card" pattern cheaply. If the greeting ever needs to become an onboarding checklist, a "what's new" panel, or role-specific quick links, that is a build decision — one a PM should make deliberately rather than by accretion on top of a cosmetic package.

• Internal admin experience (AX) investment. If the product includes a Nova back office for ops, support, or content teams, this supports a small, visible AX win: a time-aware, name-personalized greeting that makes internal tooling feel intentional. Frame it as polish, not capability — it will not move a customer metric, but it does compound with other small dashboard improvements in how the internal tool is perceived and adopted.

• Onboarding and enablement surface. The card is a natural anchor for first-run content for newly provisioned admin users: welcome copy, a pointer to internal docs, a setup checklist, or a link to release notes. That is a support-load reduction play, not a UI play. Worth piloting here before investing in a real in-app onboarding flow.

• Roadmap prioritization / sequencing. Do not make this a standalone roadmap item. Schedule it opportunistically alongside other Nova work, or run it as a small spike to test whether a personalized admin home has pull before funding a purpose-built one.

• Scope boundaries — what it explicitly does not cover. In scope: internal launch pages, seasonal/time-of-day greetings, staff "what's new" banners, gated welcome content for new accounts. Out of scope: customer-facing features, KPIs, charts, alerts, filters, workflow automation, and anything requiring business logic. It is a pure presentational card.

• A cheap decision-reversal option. Removal is one line in cards() plus a Composer update, with no migrations. That symmetry means a PM can approve a trial without provisioning a deprecation project later — a genuinely rare property in dependency decisions.

When to Consider This Package

Consider it when:

• You are already running Laravel Nova today. This is a Nova card with zero standalone value; if Nova isn't in the stack, drop it from evaluation immediately and do not let it influence an admin-panel licensing decision.
• The requirement is genuinely cosmetic — a welcome message, a first-run greeting, a seasonal touch — and not business-critical dashboard capability.
• You want a quick, low-cost validation that custom cards render correctly in your Nova version, and you need a scaffold to fork from.
• Your team is comfortable vendoring or forking a single-maintainer MIT package and owning the upgrade path permanently.
• The audience is narrow and identifiable (e.g. member-role users only), so visibility can be gated with canSee rather than shown to service accounts and shared logins.

Look elsewhere when:

• You are not on Nova, or are still evaluating admin panel options.
• You need actively maintained components. Eight stars, zero dependents, and a single December 2024 release means no community safety net and no evidence of cross-version testing. Plan on zero upstream fixes for your environment.
• You need dashboard substance — KPIs, charts, filters, alerts. Use Nova's official cards or commission a purpose-fit card.
• Procurement or security review requires dependency provenance. A near-zero-adoption package running compiled JS in privileged admin sessions may fail review, and the justification cost can exceed writing the card in-house.
• You are approaching a Nova major upgrade (3→4→5 have shifted card internals and the Vue toolchain). A card built against Nova 4 can install cleanly and render nothing on Nova 5.

Adoption caveats to attach to any approval: pin the version in composer.json, verify the nova constraint covers both your current and next Nova version, have engineering audit the bundled Vue/JS for outbound network calls before deploy, and treat a blank card as an asset-publish issue (nova:publish, cache clear, hard refresh) before escalating.

How to Pitch It (Stakeholders)

To executives: This is a micro-investment in the internal admin tools our team uses every day — a personalized, time-of-day greeting card on the Nova dashboard that makes the back office feel deliberate rather than purely functional. It is MIT-licensed, costs roughly half a day of engineering including review, has no migrations or operational footprint, and carries no customer-facing or revenue risk. The honest framing is that this is polish, not capability: it will not move a business metric on its own and should be approved as routine internal tooling upkeep, not as a standalone initiative. The downside is bounded — removal is a one-line change — which makes it a safe trial rather than a commitment.

To engineering: One composer require, one entry in NovaServiceProvider::cards(), no migrations, no scheduled work, no config to publish. Placement and copy are the only real decisions. The upside is a working scaffold for a personalized dashboard panel; the risk is that this is a single-maintainer package with no adoption, one release, and unknown Nova-version coverage — so the recommended posture is to evaluate it as a template, vendor the source, and own it rather than depend on upstream. Concretely: confirm the Nova constraint, read Card.vue's props as the authoritative config surface (undeclared meta keys are silently discarded), grep the JS for outbound HTTP calls, set a name fallback for SSO accounts, and check whether the greeting is computed client-side (timezone drift) or can be overridden server-side. Any extension beyond a greeting — onboarding checklist, release notes, quick links — is our own card, built via nova:card, not logic smuggled into meta. No migration burden, and it comes out as easily as it goes in.