Nova Cashier Overview Laravel Package

Product Decisions This Supports

• Internal tooling / build-vs-adopt decision: Weighs adopting a ready-made Nova dashboard card against building a minimal custom card or continuing to rely on the Stripe Dashboard. The honest comparison: fork-and-vendor (~3–5 days) and build-from-scratch (~3–5 days) cost roughly the same, so the adoption case rests entirely on how much of the MRR/churn/trend/plan-distribution surface we'd otherwise have to write ourselves.
• Support-deflection roadmap item: The measurable value is fewer engineering interrupts for routine billing questions ("what plan is this customer on, when does it renew, is it canceled?") plus faster finance/ops reconciliation. That is real but modest ROI — fund it as a small internal-ops initiative, not a customer-facing billing roadmap bet.
• Scope control: Position the package strictly as a read-mostly visibility and triage accelerator, not a billing engine or source of truth. Stripe and Cashier remain canonical; no billing records move. Explicitly reject scope creep toward invoices, refunds, dunning workflows, or revenue analytics.
• Target user segments: Billing support triage, customer success account reviews, finance/ops reconciliation, and manual subscription checks by staff who currently ask engineering or tab-hunt in Stripe.
• Risk posture / dependency classification: 30 stars, zero dependents, last release 2022-09-03, single maintainer, no SLA. Classify as an internal convenience tool with a named owner and documented exit path — never a strategic platform dependency, never on the critical path of a billing operation.
• Platform investment signal: The fit envelope is effectively binary — Laravel + Nova + Cashier + Stripe, all four. If Nova isn't already our internal admin standard, the Nova license plus a new admin surface dwarfs the value of one card, and the decision should be "no" without further evaluation.

When to Consider This Package

• Consider it when we already run Laravel Nova for internal admin and Laravel Cashier/Stripe is the billing source of truth, and the need is read-mostly internal visibility.
• Consider it when we want to ship a small admin capability quickly under MIT with minimal procurement friction, and can accept a time-boxed pilot over a platform commitment.
• Consider it when the team will pin versions, validate in staging against Stripe test data, review authorization and data exposure, and own a fork or fallback from day one.
• Look elsewhere (or build) when a clean Composer install fails — if resolution requires widening constraints inside the package, that's already a fork decision, and building a minimal custom Nova card against Cashier models is comparable effort with no dependency risk and full control.
• Look elsewhere when requirements include multi-gateway billing (Paddle, Chargebee, custom), complex dunning, advanced revenue analytics, strict compliance/audit trails, granular multi-tenant permissions, CRM/ERP integration, or any customer-facing billing portal.
• Avoid entirely when our admin stack isn't Nova, we aren't on Cashier/Stripe, or the subscription view would become a critical operational system without an internal owner.
• Gate before commitment: resolve composer.json constraints first; confirm whether it reads local Cashier tables, calls the Stripe API, or both; confirm whether any mutating actions (cancel/resume) exist and which key/mode they use per environment; verify Nova authorization, multi-billable-model selection, tenant scoping, and cache TTL/invalidation.

How to Pitch It (Stakeholders)

• To executives: A low-cost, MIT-licensed internal admin accelerator for teams already on Nova and Stripe/Cashier. It gives support and success faster visibility into subscription status, reducing engineering interruptions and billing escalations. It is not a strategic billing platform, not a customer-facing capability, and not a source of truth — and it should be funded as a small, time-boxed pilot rather than a roadmap investment.
• To engineering: A small Nova dashboard card that surfaces Cashier subscription data and billing metrics in the admin panel. Integration is low-effort if versions align, but the last release predates multiple Nova majors, Cashier schema evolution, and Stripe API versioning changes — so feasibility is unknown until a sandbox PoC resolves Composer constraints and renders against test-mode data. Assume we own maintenance: pin exact versions and commit the lockfile, add the card to the Nova upgrade regression checklist, review read/write behavior and authorization, and be prepared to fork or replace.
• Recommendation: Run a 2–4 week proof of concept with Stripe test data and a limited support/success cohort. Success criteria: measurable reduction in billing-related engineering interrupts, zero discrepancy between card figures and Stripe across a sampled set of accounts, and no authorization gaps in review. If any criterion fails, stop and either build a minimal custom card or fall back to the Stripe Dashboard.
• Promotion bar: Promote to production only with a named internal owner, a version-pinning policy, a Nova upgrade checklist entry, and a documented rollback plus Stripe Dashboard fallback in the support runbook. Track the most dangerous failure mode explicitly — Cashier webhook lag showing a subscription as active when it isn't — because it looks like success.