Nova Cashier Overview Laravel Package

Technical Evaluation

What it is: limedeck/nova-cashier-overview is a small, MIT-licensed Laravel Nova card that renders Laravel Cashier/Stripe subscription metrics — active, trialing, canceled counts, MRR, churn and growth trends, plan distribution — inside the Nova admin panel. It is a read-mostly visibility surface. It owns no billing records and is not a billing engine.

Architecture fit: The fit envelope is narrow and effectively binary: Laravel + Nova + Cashier + Stripe. If all four are already in place, the card is a cheap addition to an existing admin surface. If any are missing — particularly Nova, which carries a paid license — adopting this package means introducing a new platform dependency to deliver a single dashboard card. That trade is not worth endorsing. There is no partial-fit scenario worth pursuing.

Value proposition: The opportunity is support deflection, not revenue capability. The measurable win is fewer engineering interrupts for routine billing questions ("what plan, when does it renew, is it canceled") plus faster finance/ops reconciliation. Real but modest ROI — and achievable through several cheaper paths, which is precisely why this must be framed as a time-boxed accelerator rather than a roadmap bet.

Integration feasibility: Technically low-effort in a compatible stack: Composer install, register the card/tool in NovaServiceProvider, optionally publish config, clear caches. The binding constraint is version alignment, not implementation complexity. The last tagged release is 2022-09-03, predating multiple Nova majors, Cashier schema evolution, and Stripe API version changes. Treat feasibility as unknown until a sandbox proof-of-concept resolves Composer constraints and renders the card against test-mode Stripe data.

Adoption and longevity signals: 30 stars, 0 dependents, no vendor SLA, single-maintainer risk, and roughly three years without a release. Disqualifying for a strategic platform dependency; acceptable only for an internal convenience tool with a named owner and a documented exit path.

Technical risk (ranked):

1. Compatibility drift — Composer conflicts or runtime breakage on current Nova/Laravel/PHP/Cashier. Highest likelihood; moderate effort to resolve via fork and widened constraints.
2. Stripe API drift — if the card calls Stripe directly rather than reading local Cashier tables, pinned API versions or deprecated endpoints may fail silently or return partial data.
3. Data exposure — customer names, emails, plan and revenue figures in an admin surface. Nova authorization, tenant scoping, and role gating must be verified, not assumed.
4. Write actions — source review must confirm whether any cancel/resume/mutate actions exist. If so, they require policy gating, audit logging, and explicit approval before production.
5. Abandonment — low probability of upstream fixes; assume fork ownership from day one.

Key questions before commitment:

• Which Laravel, PHP, Nova, and Cashier versions does composer.json support, and does it install cleanly on our current stack?
• Does it read local Cashier tables, call the Stripe API, or both? That determines caching strategy, rate-limit exposure, and failure behavior.
• Are there mutating actions, and if so, which Stripe key/mode is used per environment?
• How are Nova authorization, multi-billable-model selection, and tenant scoping handled?
• Does configurable caching exist and is it safe? Stale MRR shown to finance is a credibility problem.
• What is the fallback if the card breaks during a Nova upgrade — feature-flag off, or fork-and-patch?

Integration Approach

Stack fit: Green-light only where Nova is already the internal admin standard and Cashier/Stripe is the billing source of truth. Do not introduce Nova to obtain this card — a Nova license plus a new admin surface dwarfs the value of one dashboard card. Do not use it where billing runs through Paddle, Chargebee, or a custom gateway.

Build vs. adopt framing: Present three options with effort estimates:

• Adopt (pinned): ~1–3 days for PoC plus security review, contingent on clean Composer resolution. Lowest cost, highest drift risk.
• Fork and vendor: ~3–5 days including constraint widening and asset rebuild. Recommended if the PoC looks promising but versions conflict — converts abandonment risk into owned code.
• Build a minimal custom Nova card: ~3–5 days against Cashier models only. Comparable effort, full control, no dependency risk. Often the better answer if the required metrics are narrower than what ships here.

The honest conclusion: because fork and build cost roughly the same, the adoption case rests entirely on how much of the MRR/churn/trend surface we would otherwise have to write ourselves.

Migration path: None in the data sense — Stripe and Cashier remain the source of truth and no billing records move. Treat it strictly as an additive admin UI. Run it in parallel with existing Stripe Dashboard workflows during the pilot so staff have a reference to validate against, and preserve the Stripe Dashboard as the documented fallback for every workflow the card supports.

Compatibility gate: Resolve composer.json constraints before any UI work. Pay attention to Nova major-version card/tool registration APIs and Cashier schema fields (stripe_status, ends_at, trial_ends_at) that may have shifted since 2022. Pin exact versions, commit the lockfile, review transitive dependencies. If resolution requires widening constraints inside the package, that is already a fork decision — record it as such.

Sequencing:

1. Scope confirmation — write down the specific questions the card must answer. Reject scope creep toward invoices, refunds, dunning, or revenue analytics.
2. Sandbox PoC — install non-production with Stripe test keys and seeded active/trialing/canceled/past-due subscriptions; verify the card renders and numbers reconcile against the Stripe Dashboard.
3. Source and security review — confirm read vs. write behavior, authorization hooks, tenant scoping, and what customer data reaches the browser.
4. Decision gate — adopt pinned, fork/vendor, or replace with a custom card. Record the rationale.
5. Time-boxed pilot — 2–4 weeks with a named support/success cohort. Instrument engineering interrupts and lookup time before and after.
6. Production decision — promote only with an assigned internal owner, version-pinning policy, Nova upgrade checklist entry, and documented rollback.

Pilot 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 found in review. If any fail, stop and either build the custom card or rely on the Stripe Dashboard.

Operational Impact

Maintenance: Assume ownership even if we don't fork. A 2022 release with minimal community activity means upstream fixes should not be counted on. Budget recurring effort for dependency bumps on every Laravel/Nova/Cashier upgrade, Composer constraint maintenance, and Stripe API compatibility checks. Add the card to the Nova upgrade regression checklist — this is the single most likely source of future breakage.

Support: Community/GitHub only; no vendor SLA, no security disclosure process. Define an internal escalation owner and ensure the card is never on the critical path of a billing operation. If it fails, staff must be able to fall back to the Stripe Dashboard with no customer impact. Document that fallback in the support runbook.

Scaling: Admin-panel concurrency is low, so user load is a non-issue. The real scaling risks are (a) Stripe API rate limits if the card fetches live rather than reading local tables, and (b) slow aggregate queries over large subscriptions tables when computing MRR and churn. Caching is the stated mitigation — verify TTL and invalidation are appropriate, because stale MRR shown to finance is worse than no MRR at all.

Failure modes to monitor:

• Card fails to render after a Nova or Laravel upgrade (most likely).
• Composer resolution breaks on PHP/framework bumps, blocking deploys.
• Stripe API deprecation or key rotation produces empty or erroring metrics.
• Cashier webhook lag makes local state diverge from Stripe, so the card shows a subscription as active when it isn't — the most dangerous failure because it looks like success.
• Authorization misconfiguration exposes customer and revenue data to under-privileged Nova users.
• Published JS/CSS assets go stale after a rebuild.

Instrument application error tracking, Stripe rate-limit and error responses, and cache hit/miss on the metric queries. Alert on card render failures and on empty or zeroed metric payloads, which usually indicate an integration break rather than genuinely zero revenue.

Ramp-up: Low for engineers familiar with Nova (hours to read the source and register the card); moderate for support/success staff who need a short walkthrough on reading statuses and trial/renewal context. The larger ramp-up cost is organizational: naming an owner, writing the fallback runbook, and adding the upgrade checklist entry before production promotion. Budget that people-time explicitly — it is the difference between a maintained internal tool and an orphaned dashboard that silently lies to finance.