Visual Feedback For Laravel Laravel Package

Product Decisions This Supports

• Decide what "feedback" means for your product before you decide on the package. The listing sells toasts, notifications and progress indicators; the code ships an in-page feedback widget (floating trigger → modal → screenshot capture → delivery via mail/webhook/database). These are different products. Adopting this is a decision to capture user-reported issues in-app, not to prettify flash messages. If you want toasts, stop here.
• Build vs. buy vs. self-host for feedback capture. The alternatives are a hosted widget (Intercom, Canny, Sentry user feedback) or a hand-rolled form. This is the self-hosted middle path: MIT, no vendor, no build step, data stays on your infrastructure. That is a genuine differentiator if you can't send screenshots to a third party.
• Turning qualitative complaints into reproducible reports. The value proposition is measurable: reports per week, share arriving with a usable screenshot, median time-to-reproduce versus your current email/Slack baseline, delivery failure rate. That directly informs roadmap prioritisation on bug-prone surfaces.
• Delivery channel as a product decision, not a config value. mail = a human reads an inbox. webhook = reports land in the ticketing tool you already run (one queue, not two). database = you now own a triage UI, retention policy and prune schedule. Most teams should pilot mail and graduate to webhook.
• Field shaping per surface. Each field is off / optional / required, defaultable from env and overridable per mount — so an internal admin panel and a customer-facing page can ask different questions without environment churn. Authenticated reporters are identified by the auth guard, so email/phone can be dropped for them.
• A privacy and retention decision that lands on the PM's desk. Screenshots capture whatever was on screen. The package insists on a private disk but ships no redaction, no DSAR tooling and no default retention_days. Setting retention, scheduling the prune, and confirming backups inherit the same classification is a policy call you now own.
• Maturity risk as an explicit trade. Six stars, zero dependents, one maintainer, MIT. That doesn't disqualify it — releases are actively fixing real production edges (bundle ordering under wire:navigate, PostgreSQL type errors in the report browser, billed S3 PUT/DELETE on refused uploads) — but it means pinning the version and reading changelogs becomes a standing commitment, not a one-off.

When to Consider This Package

Consider it when:

• You want first-party, self-hosted in-app feedback with screenshots, on a small-to-mid Laravel app, and no front-end build pipeline exists — "zero build step" is a real advantage here.
• The first target is an internal tool, admin panel or beta surface, where a screenshot.strategy=dom capture (no browser permission prompt) is good enough and the operational tail is smallest: mail-only, no migration, no triage UI.
• You already run a ticketing system — the webhook channel lets reports flow into one queue you already staff.
• You use Livewire (including wire:navigate), Inertia or plain Blade. The widget is a Livewire component, so @livewireScripts/@livewireStyles are already in place.
• You can commit to the three things that make it work at all: a recipient (VISUAL_FEEDBACK_MAIL_TO is empty by default and the mail channel silently marks itself unavailable), a running queue worker (every channel dispatches a job — a default database queue with no worker accepts and drops reports), and re-publishing assets after every composer update (the four bundles under public/vendor/visual-feedback are copies, not symlinks).

Look elsewhere when:

• You actually need toast/flash helpers. This is not that package.
• You need vendor SLAs, a support contract, or a strict dependency gate on maturity — six stars and zero dependents will not clear it. Buy the risk down structurally (one include, easy removal) rather than organisationally.
• You want a hosted feedback product with public voting, roadmap visibility or analytics. Canny/Intercom solve a different problem.
• You cannot own retention, redaction and DSAR for screen captures.
• You cannot absorb the recurring deployment discipline: asset re-publish, CSP entries for all four bundles under the same script-src source, and a queue worker monitoring story.

How to Pitch It (Stakeholders)

For executives: This gives users a way to report a problem from inside the product, with a screenshot and the page context attached, instead of an email that says "it's broken." It's MIT, self-hosted, no vendor contract, no data leaving our infrastructure, and roughly three lines in the layout to switch on. The risk is that it's a young, single-maintainer package with a small community — so we contain it: one include in a single partial, a 30-day pilot on one internal surface, mail-only, and a decision at day 30 on five metrics.

For engineering: No build step, fluent PHP API, Livewire-native. Three concerns to plan for, all of them silent if missed: the config and asset publishes are hard requirements (assets are copies — re-publish per deploy; php artisan about reports staleness), every channel dispatches a queued job, and the CSP must permit all four bundles. The database channel needs its own migration tag before it will work. Keep the integration in one partial so removal is a one-line operation.

For support/ops: Reports arrive either in an inbox or in our existing ticketing tool, with capture strategy and whether the screenshot was edited recorded alongside — so we can tell "the user drew on it" from "the DOM fallback produced a degraded image" without emailing them back. The failure mode to watch is silence: no recipient set, MAIL_MAILER=log, no worker, or stale bundles all accept a report and drop it. Alert on the package's "no channel was enabled and available" log line from day one.

The ask: approve a 30-day pilot — mail-only, one internal surface, screenshot.strategy=dom, no database channel, no migration. Judge it at day 30 on reports per week, usable-screenshot share, median time-to-reproduce versus baseline, delivery failure rate, and whether reports land in triage without a human re-filing them. Then either promote to the webhook channel or remove the include.