Scoutify Laravel Package

Product Decisions This Supports

• Feature scoping: "global search / ⌘K palette" — ship now or defer? The package collapses the UI build (keyboard trigger, dialog, grouped results, focus management, dark mode, WCAG AA markup, i18n) into an install command plus per-model method overrides. The decision it unblocks is whether a polished search affordance fits this quarter's roadmap without consuming a sprint.
• Build vs buy for the presentation layer only. Scoutify is a UI shell on top of Scout — it does not do relevance, ranking, synonyms, typo tolerance, or faceting. So the decision is: buy the shell, spend the team's time on the parts that actually differentiate (index design, globalSearchBuilder() scoping, ranking expectations), not on modal plumbing.
• Roadmap sequencing across surfaces. Cheap enough to be a "polish" item for admin panels and internal tools already running Livewire, while customer-facing search still deserves its own design and relevance review.
• Security/compliance posture. Secure-by-default visibility (guests denied, policy/gate checks, Spatie permission/role rules, fail-closed when a dependency is missing, plus a signed preview route that reuses the same authorizer) supports a "we can ship multi-model search without opening a data-leak ticket" decision in multi-tenant or regulated contexts.
• Document/DAM-style product bets. HasGlobalSearchPreview with inline PDF/image/video rendering, pre-signed URLs where the disk supports them, and an opt-in scoutify:download event is a genuine lever: it can remove a preview subsystem from the backlog.
• Go-to-market localization. Ships pt_BR/en/es and NFD accent-insensitive matching (padrao finds and highlights Padrão), which supports launching search in Brazilian/LATAM markets without a dedicated localization workstream.
• Adoption risk decision. 1 star, 0 dependents, single maintainer, latest release dated 2026-08-16 with readme/docs/changelog/releases present. The PM decision isn't "adopt" — it's "adopt with a priced exit" (pin the version, wrap our Blade usage in our own components, budget a fork day; MIT makes that cheap).

When to Consider This Package

Consider it when:

• You are on Laravel 11–13 with Livewire 3/4 and already use (or are about to use) Scout with Meilisearch, Algolia, Typesense, or the database driver. Without Scout, this adds nothing.
• You want the specific affordances it ships: grouped multi-model results, session-backed recent searches, auto-discovered subtitles with HTML sanitization, any Blade Icons pack, dark mode, keyboard accessibility.
• The surface is internal/admin or an authenticated product area where a modal palette is the expected convention and SEO is irrelevant.
• You value the zero-config discovery and the scoutify:searchable --dry-run codegen as an onboarding accelerator for a team new to Scout.

Look elsewhere or proceed with caution when:

• Public, SEO-critical search. The modal is a Livewire component, not a crawlable results page with facets and pagination. You need real search pages.
• Non-Livewire front ends (Inertia/React/Vue, separate SPA). You'd be adopting a Blade/Livewire stack you don't ship.
• Strict change-management environments. scoutify:searchable rewrites model files in place, and boot-time model discovery needs review against config-caching and deploy pipelines.
• Relevance is the product. Meilisearch's word-prefix behavior means infix expectations ("ano" inside "Mariano") fail unless you override globalSearchBuilder(); the package gives you hooks, not solutions.
• You cannot accept a single-maintainer dependency on a customer-facing surface. Fork it (MIT, small surface) or build the modal in-house.
• Treat maturity honestly: docs and releases exist, but community validation is effectively zero. This is "promising pre-adoption," not "battle-tested."

How to Pitch It (Stakeholders)

To executives: "This is roughly a two-day integration that gives us the ⌘K search experience users already expect from Linear, Notion, and Slack — on top of search infrastructure we either already run or were going to adopt anyway. No new vendor, no new search bill, MIT-licensed, and removable in under a week if it disappoints. The value is avoided engineering cost and a faster roadmap, not a technology bet."

To engineering: "It's a thin, opinionated Livewire UI over Scout you configure yourself. The extension points are clean — GloballySearchable, HasGlobalSearchVisibility with a fluent rule builder, HasGlobalSearchPreview, and a per-model globalSearchBuilder() so our existing scopes and filters survive. Authorization is secure-by-default and fails closed. Known constraints: Meilisearch prefix matching, in-place model file edits from the artisan command, boot-time discovery, and a single maintainer with zero dependents — so we pin the version, vendor or fork if maintenance stalls, and keep our template usage behind our own components."

Risk framing for both: propose a bounded pilot on one internal or admin surface with explicit success criteria — time-to-first-result, keyboard-only usability, zero authorization regressions, and measured onboarding effort for a new model — plus a pre-agreed fallback (fork under MIT) if the package goes stale.