Laravel Nps Laravel Package

Product Decisions This Supports

• Build vs. buy for customer-feedback capture: The package supplies the undifferentiated plumbing behind an NPS program — survey definitions, response storage, and score calculation — so the decision shifts from "do we license a feedback SaaS?" to "do we need a vendor at all for a single in-app NPS prompt?"
• Roadmap sequencing for retention work: Makes a lightweight NPS loop cheap enough to ship as a v1 experiment (post-onboarding or post-support-ticket survey) before committing roadmap capacity to a full voice-of-customer platform.
• Feature scoping: Lets the team separate collection (what this package handles) from activation (dashboards, alerting, segmentation, follow-up workflows), clarifying which parts are ours to build and which are commodity.
• Instrumentation strategy: Supports deciding whether feedback capture lives inside the product (first-party, event-linked, joinable to account data) versus bolted on via a third-party embed — first-party data is typically more valuable for cohort and churn analysis.
• Laravel 11 compatibility (2.2.0): Removes the framework-upgrade blocker. Teams planning or mid-migration to Laravel 11 can now include this in scope without a fork or a pinned framework version; it also signals the package is maintained, which lowers the "abandoned dependency" risk in a build-vs-buy call.

When to Consider This Package

Adopt when most of the following hold:

• You are on Laravel (now including 11.x) and want NPS data in your own database, joined to users, accounts, plans, and lifecycle events — not trapped in a vendor's silo.
• Scope is genuinely NPS: one-question, 0–10 scoring with promoter/passive/detractor bucketing. If you need multi-question CSAT/CES surveys, branching logic, or complex survey authoring, look elsewhere.
• You will own the presentation layer. This is a backend/data package; the UI, send cadence, throttling, and follow-up flows are your work. Budget for that honestly.
• Data residency, PII, or procurement constraints make a third-party SaaS awkward — keeping responses in-house sidesteps a vendor review.
• You want a fast, reversible experiment. Small surface area, few dependencies, easy to remove if the NPS loop doesn't earn its keep.

Look elsewhere when:

• You need enterprise VoC capabilities — trend dashboards, closed-loop workflows, CRM sync, benchmarking, multi-channel distribution. A vendor will be cheaper than building these.
• Non-Laravel or polyglot stack, or a services split where feedback capture doesn't belong in the monolith.
• You lack capacity to build and maintain the survey UX and delivery pipeline — the package is the easy 20%.
• You need guaranteed long-term support. This is a small, single-maintainer-adjacent package; the 2.2.0 release shows activity, but there's no commercial SLA. Assess bus-factor and pin versions.
• Statistical rigor matters (weighted sampling, response-rate correction, significance testing) — you'll be building the analytics yourself regardless.

How to Pitch It (Stakeholders)

For executives: This is a small, free, open-source Laravel component that lets us run Net Promoter Score surveys using our own infrastructure instead of a subscription. The 2.2.0 release adds Laravel 11 support, so it's compatible with our current framework plans and is actively maintained. It gives us the data-capture layer only — dashboards and follow-up workflows remain ours or a future vendor's — so treat it as a low-cost way to test whether a structured NPS program is worth further investment, not as a replacement for a voice-of-customer platform. Risk is low and reversible: minimal dependencies, data stays in-house, and removal is straightforward if the experiment doesn't justify itself.

For engineering: Backend package providing NPS survey models, migrations, response collection, and score calculation — no frontend opinions, no opinionated delivery mechanism. Laravel 11 compatibility landed in 2.2.0, clearing the upgrade blocker. Integration is additive: config, migrations, and API surface, with our own UI on top. Note the maintainer footprint is small and there's no LTS guarantee; recommend pinning the version, covering the integration with tests at our boundary, and isolating it behind a thin service layer so swapping to a vendor later is a contained change rather than a rewrite.

Recommendation: Approve as a scoped spike behind an internal abstraction, with a decision checkpoint after one quarter of response data on whether to keep, extend, or replace with a vendor.