Laravel Kustomer Laravel Package

Product Decisions This Supports

• Build vs. buy for a feedback loop. This package sits between "build it ourselves" and "buy a SaaS tool" (Canny, UserVoice, Hotjar, Feedback Fish). It's a self-hosted Laravel-native option: MIT-licensed, no per-seat or per-response fees, data stays in your own database. That makes it the natural candidate for the "cheap and good enough" branch of the decision.
• Whether feedback is table stakes or differentiating. If in-app feedback is a checkbox feature (most B2B tools), adopting a package is the right call and engineering time goes to the roadmap. If feedback quality is the product (e.g., a CX or research platform), the package is only a starting point and you should plan to own the schema and UI.
• Capturing structured product input instead of ad-hoc channels. The widget framing implies configurable questions stored server-side — which converts scattered "customer said X in Slack" signals into queryable data you can segment by user, tenant, or plan and cite in roadmap reviews.
• Extensibility as a decision lever. "Extensible" matters for PMs when the widget must attach feedback to domain objects — a tenant, an order, a feature flag, an onboarding step. A SaaS widget that can't see your data model forces compromises; a package with extension points lets you link feedback to the entities you actually want to analyze.
• Data residency and compliance posture. Self-hosting removes a vendor from the DPA/subprocessor list and keeps customer PII in infrastructure you already govern — often the deciding factor in enterprise or regulated deals.
• Scope decisions on admin surfaces. Adopting it means deciding whether you also expose an internal triage view, or export feedback into the tools your team already lives in (Linear, Jira, Notion).

When to Consider This Package

Good fit when:

• You're on Laravel, the team is comfortable in PHP/Blade, and you already have auth/users/tenants to attach feedback to.
• You need modest volumes of qualitative feedback — tens to low thousands of responses per month — not a real-time analytics platform.
• You want the widget to match your brand, domain model, and permissions rather than embed a third-party iframe.
• Compliance or procurement makes a new SaaS vendor expensive.
• The timeline is short: a package plus light customization is typically a fraction of a sprint versus building capture, storage, and an admin view.

Look elsewhere when:

• You need omnichannel (email, chat, mobile SDKs, in-app messaging) or enterprise workflows — routing, SLAs, assignments, sentiment/NPS benchmarking, cohort analytics. That's a CX platform, not a widget.
• Your frontend is a decoupled SPA or mobile app; a Blade-oriented package may not give you the API surface you need without significant work.
• You need guaranteed vendor support. 418 stars and a single-package maintainer is a real bus-factor risk — validate release cadence, open-issue responsiveness, supported Laravel/PHP versions, and migration path across major framework upgrades before committing.

Verify before adoption (do not assume):

• That it ships migrations and stores responses in your database (vs. proxying to a third-party service — the "Kustomer" name invites confusion with the CRM of the same name).
• Localization, accessibility, and mobile behavior of the widget.
• Documented extension points and whether customization survives package updates.
• Actual license and maintenance status of the tagged release.

How to Pitch It (Stakeholders)

For executives: A low-cost, self-hosted way to start closing the feedback loop with customers this quarter instead of next. MIT license, no subscription, no new vendor in procurement or the privacy review, and customer data stays in our own systems. The trade-off is explicit: we take on maintenance of a small, single-maintainer open-source component. We mitigate that by keeping it behind an internal interface so it can be replaced, and by budgeting a small amount of ongoing upgrade time.

For engineering: It's a Composer package with migrations and publishable config, so integration is measured in days, not weeks. The value is in the extension points — we can bind feedback to tenants, users, and domain objects without forking. Recommended guardrail: wrap submission and retrieval in our own service/repository so the package is an implementation detail, not a dependency baked across the codebase.

Ask: A short timeboxed spike (1–2 days) to confirm database-backed storage, extension points, and framework compatibility, then a decision to adopt, fork, or build minimally in-house.