- What is mydnic/laravel-kustomer and is it a Kustomer CRM integration?
- It is a Laravel-native package that ships an extensible customer feedback widget as a Blade component, along with publishable config and migrations and a fluent client described as a wrapper for the Kustomer API. The naming collides with the commercial Kustomer CRM platform, so call that out early in procurement and security review. Treat the CRM association as something to verify rather than assume, and confirm what the client actually talks to on the tagged release.
- Which Laravel and PHP versions does this package support?
- The package is built as a standard Laravel package with an auto-discovered service provider, so the happy path assumes a conventional Laravel app. The recommended integration target is Laravel 10, 11 or 12 on PHP 8.1 or newer. Laravel packages often lag major framework releases, so read the composer.json constraints and the CI matrix on the current tag rather than assuming a recent release date means full coverage.
- How do I install and configure the package in a Laravel application?
- Publish the config and migrations, run the migrations, add the widget component to your layout, then configure routing, the auth guard and any notification channels. Budget one to three developer-days for a technical spike that proves the widget renders, persists feedback and fires notifications. Expect one to two weeks end to end once you include visual design, privacy review, multi-tenant scoping and QA.
- Can I use the feedback widget in a headless, SPA or mobile frontend?
- The feedback surface is rendered with Blade, which fits a monolithic or modular-monolith Laravel app where the widget lives in the same deployable as the product. It is a poor fit for a decoupled architecture unless there is a JSON submission endpoint or a standalone JS bundle you can mount elsewhere. Verify that before committing, because otherwise the package only serves the Laravel-rendered site or an internal admin surface.
- Will the widget's CSS and JS conflict with my Vite or Tailwind setup?
- Packages that ship compiled CSS and JS frequently collide with the host's Vite version, Tailwind major or Content Security Policy, and that is historically the highest-probability source of integration pain in this class of package. Check whether the bundled styles are scoped or global, since global styles leaking into the host app is a common and annoying regression. Confirm the asset pipeline before doing anything else, and mount the widget in a real layout during the spike.
- How are anonymous versus authenticated submissions handled, and is there spam protection?
- Feedback widgets typically support both authenticated and anonymous submissions, and the choice drives your auth guard, validation and data model. Public submission routes without rate limiting are both an abuse vector and a privacy problem, so confirm what ships out of the box rather than assuming. If nothing is bundled, wrap the route in Laravel's throttle middleware, add bot controls and decide how you identify or anonymise respondents.
- What data does the package store, and where do screenshots or attachments land?
- Feedback payloads usually carry user identifiers and free text, and may also capture screenshots, DOM snapshots, page URLs and user agents. Establish exactly what is persisted and where attachments are written before your privacy review, since this is the decision that is hardest to reverse. Also note the package writes tables directly into your host database, so table naming, foreign keys and rollback behaviour are effectively permanent choices.
- Does it support multi-tenancy or per-tenant scoping of feedback?
- This is not confirmed by the package description, so test it during the spike if you run a multi-tenant application. Submissions may need to be scoped by tenant through a custom field, a global scope or a fork of the migration and model layer. Confirm documented support before committing to a shared-database design, because retrofitting tenant keys after launch is painful.
- Are notifications queued, and what extension points does the package expose?
- The widget typically fires mail, Slack or webhook notifications on submission, and you need to know whether those are queued or synchronous before you go live with a queue worker. Extensibility is a claim rather than a contract, so validate it against real extension points such as events, contracts and custom-field registration. Check that those hooks are covered by tests, otherwise you are coupling your customisations to internals that can change on any release.
- Is it safe to run in production given the single-maintainer bus factor, and what are the alternatives?
- Around 418 stars and a single maintainer is fine for a feedback widget but not fine for anything on the critical path, so treat it as adopt with a fork contingency. Check the release cadence and issue-response history over the last twelve months, and pin a version you have actually tested. If the risk is unacceptable, the realistic alternatives are Typeform, Google Forms, Intercom surveys or a small bespoke feedback table of your own.