Nova Kustomer Laravel Package

Technical Evaluation

Architecture fit. mydnic/nova-kustomer is a Laravel Nova Tool — a package that registers a ToolServiceProvider, ships compiled front-end assets, and adds a menu entry inside the Nova admin panel. Architecturally it is a thin presentation-layer plugin: a Vue view plus server-side calls to the Kustomer REST API. That shape fits our stack only if two preconditions hold: (1) the internal admin surface where support/CS agents work is already Nova, and (2) we want Kustomer context embedded next to our own models (orders, accounts, tenants) rather than sending agents to a second tab. If either is false, the package has no architectural role and a simple link-out to Kustomer's own inbox is the better design. Note the package is a convenience affordance, not infrastructure — nothing else in the system should depend on it.

Integration feasibility. Superficially a one-command install (composer require, register the provider, publish config, set an API key). In practice, a December 2019 publish date places this in the Nova 2/3 era: webpack/Mix asset pipeline, Vue 2 components, and a composer.json almost certainly constrained to Laravel 5.8–6.x and PHP 7.x. Nova 4+ moved to Vite and Vue 3, and Nova 5 requires PHP 8.2+. The likelihood that the tool's compiled JS entry loads and mounts unmodified on a current Nova install is low, and the Composer resolver will likely block the install before we even get that far. Treat "install it" as a spike, not a plan.

Technical risk. High across the board:

• Abandonment — no release in ~6 years, single maintainer, 18 stars, 0 dependents. There is no community canary; we would be the only ones exercising this code.
• Security — an API key for a CRM holding customer PII. We must confirm the key is read server-side only and never serialized into the Nova payload. No security disclosure path exists upstream.
• Vendor drift — Kustomer's API surface has evolved, and the vendor itself has changed ownership (Meta acquisition, subsequent divestiture). Either vector can silently break JSON parsing with no upstream patch coming.
• Scoring — a 0.09 health score with an "opportunity" signal of 13.84 reads as cheap to replace, not cheap to adopt. That is the correct interpretation.

Key questions.

1. Which Nova major are we on today, and is it pinned to the license tier that supports tools? (Determines whether a fork is even viable.)
2. What Kustomer surface do agents actually need — customer profile, conversation timeline, or write-back (notes/tags)? Read-only is a 1-day build; write-back multiplies scope.
3. Is there a maintained alternative? Kustomer's native embeddable widget, its Slack/Salesforce/Shopify integrations, or a generic API card may cover 80% of the need with zero owned code.
4. Does the tool centralize Kustomer auth server-side, or does it call the API from the browser? The latter is a hard stop.
5. Who owns the fork if we take one, and what is our exit criterion for deleting it?

Integration Approach

Stack fit. Laravel (+ Nova) on the host side, Kustomer REST on the remote side. The package's only genuinely reusable asset is its API-call shape and field mapping — the front end will not survive a Nova 4/5 upgrade. Plan to keep the former and discard the latter.

Migration path. Two viable routes, decided by a timeboxed spike:

• Fork — vendor the repo as a path repository, bump composer.json (php: ^8.2, laravel/framework: ^11, laravel/nova: ^5), replace the Mix build with Vite, port Vue 2 components to Vue 3, and re-register the tool in NovaServiceProvider::tools(). Viable only if the diff stays under roughly 2–3 days.
• Rebuild — implement a Nova Card (not a Tool) backed by a small KustomerClient service class with caching and rate-limit handling. This is the default recommendation: the surface area required is small, the result is maintainable, and it drops the abandoned-dependency flag from composer audit/Dependabot entirely.

Compatibility. Assume breakage at three seams: Composer platform constraints, the Nova asset-registration API, and Kustomer API versioning. Verify each independently in the spike rather than discovering them stacked. If the host app is on Nova 3 or earlier (unlikely but possible), the original package may run with minimal patching — confirm before committing to a rewrite.

Sequencing.

1. Spike (0.5 day): attempt install in a throwaway branch; record every conflict; read the source for the API call and auth pattern.
2. Decide (0.5 day): fork vs. rebuild vs. buy (native Kustomer embed). Default to rebuild.
3. Build (2–4 days): server-side Kustomer client with config-driven credentials, short-TTL cache, per-record lazy loading, and a fail-soft empty state.
4. Expose (0.5 day): Nova Card on the relevant detail views only — not on index pages.
5. Harden (0.5 day): feature flag, key rotation path, logging on upstream errors, README with ownership and upgrade notes.
6. Retire the original dependency from composer.json entirely; keep the repo link in a comment for provenance.

Operational Impact

Maintenance. Effectively 100% ownership from day one. Even the fork route transfers all maintenance to us while preserving a misleading upstream provenance — contributors and scanners will assume it is supported. Budget recurring effort for two independent upgrade streams: Kustomer API changes and Nova major releases (roughly annual). The rebuild route collapses this to a single small file we fully understand.

Support. No maintainer SLA, stale issues, no disclosure process. When it breaks, it breaks silently and we debug a stranger's 2019 code. The MIT license is the one unambiguously good property here: forking and relicensing internally is clean, no legal review needed.

Scaling. The real hazard is request amplification. If the tool renders on Nova index pages, a 50-row table can mean 50 Kustomer API calls per page load, against per-org rate limits we do not control. Constrain it to detail views, cache aggressively (30–60s TTL is plenty for CRM context), batch where the API allows, and degrade to a "View in Kustomer" link when throttled.

Failure modes.

• Kustomer outage or rate limit → must render a neutral empty state, never a stack trace or spinner-of-death in the admin panel.
• API key exposure → the highest-severity failure; enforce server-side-only calls and a rotatable config value.
• Schema drift → Kustomer response shape changes break parsing silently; add a defensive parse and a log line.
• Nova upgrade → asset pipeline breakage presents as a blank card with a console error; easy to miss without a smoke test.
• Scanner noise → an unmaintained dependency generates perpetual audit findings that train the team to ignore them.

Ramp-up. A mid-level Laravel developer reads this package in under a day — it is small, which is also why rebuilding is cheap. The hidden cost is not comprehension, it is the archaeology of making 2019 front-end tooling work against a 2025 Nova build. Realistic end-to-end estimate for an equivalent, owned, maintained integration: 3–5 developer-days, with the spike de-risking the upper bound.

Recommendation: do not adopt as a dependency. Use it as a reference implementation for the Kustomer API call and auth pattern, then rebuild as a scoped Nova Card. The package's value is that it proves the integration is small — not that it is a solution.