Repository Laravel Package

Product Decisions This Supports

• Build vs. buy on search: v0.3.0's Laravel Scout support materially changes this calculus. If your roadmap has "add search to the product," this package can now sit behind Scout's official driver interface rather than requiring a bespoke integration — evaluate it as a candidate before scoping custom work.
• Roadmap sequencing: Scout support unlocks use cases previously out of reach (full-text search across Eloquent models, federated search, relevance tuning) without adding a new infrastructure dependency to the stack. If search was parked pending an engine decision, it can be unparked.
• Migration/upgrade planning: Dropping the model() method is a hard break. If anything in the codebase or a downstream service calls it, that work must be scheduled before any version bump — this is a PM-visible line item, not just an engineering detail.
• Feature parity vs. competitors: Scout integration is a differentiating capability worth checking against alternatives; it may let you defer a paid search SaaS commitment for another quarter or two.
• Use cases: internal admin search, catalog/product discovery, documentation lookup, and any read-heavy surface where a pluggable driver (database, Algolia, Meilisearch, Typesense) is preferable to hard-coding one backend.

When to Consider This Package

Adopt when:

• You are already using or planning to use Laravel Scout, and want search behavior layered on top rather than written from scratch.
• You need a driver-agnostic search layer so the backend can change (database → Meilisearch → Algolia) without rewriting application code.
• Your team is comfortable pinning a pre-1.0 dependency and tracking its changelog, or you can isolate it behind an internal interface.
• The model()-free API surface is sufficient for your query patterns — confirm this explicitly before committing.

Look elsewhere when:

• You depend on model() or its semantics; migrating off it is a blocker with no stated replacement path in these notes.
• You need API stability guarantees for a long-lived, customer-facing surface. A 0.3.0 release that removes a public method is a signal the API is still in flux; expect more breaks before 1.0.
• You require documented deprecation windows and upgrade guides — none are indicated here.
• Search is a core differentiator requiring deep relevance tuning, ranking control, or analytics beyond what a thin Scout wrapper provides; a dedicated engine or vendor is the better bet.
• You are not on Scout and have no intention of adopting it — the headline feature provides no value, while the breaking change still costs you.

Action before adoption: get a written answer on what replaces model(), and confirm whether the removal is permanent or a rename.

How to Pitch It (Stakeholders)

To executives: This package just became considerably more useful — it now plugs into Laravel Scout, the framework's standard search layer, which means we can add search functionality without building a custom integration or locking ourselves to one search vendor. That's a meaningful reduction in both build cost and vendor risk on any search-related roadmap item. The caveat is maturity: this is a pre-1.0 package, and this very release removed a public method, so I'd position it as "evaluate now, commit after the next release stabilizes" rather than "adopt today."

To engineering: Two changes in v0.3.0. The upside is Scout support — a standard, well-understood integration path and backend flexibility. The cost is that model() is gone with no stated migration path in the release notes, so anyone on 0.2.x needs to audit call sites first. Recommendation: spike it behind an internal abstraction on one non-critical surface, confirm the replacement for model(), and hold broad adoption until the API settles — ideally at or near 1.0. Budget for at least one more breaking change before then.