Typesense Scout Laravel Package

Product Decisions This Supports

• Search stack selection (build vs. buy vs. adopt). This package is a candidate input to the "what powers full-text search?" decision — catalog search, marketplace/listing search, internal admin search, help-center/docs search. It sits alongside Postgres tsvector, Meilisearch, Algolia, OpenSearch, and a direct Typesense client.
• Backend reversibility as a product asset. Because it plugs into Laravel Scout, the model-facing API (searchable(), Model::search()) is unchanged regardless of engine. That means the vendor decision can be deferred or reversed without touching product code — the genuinely valuable property here, more than the driver itself.
• Upgrade-path scoping. Its stated Laravel 12/13 + PHP 8.4/8.5 support makes it relevant to a platform upgrade roadmap: if a Laravel major bump breaks the current search integration, this is one route to keep search alive through the migration.
• Feature justification for search investment. Typesense's differentiators — typo tolerance, faceting, geo filters, sub-50ms responses — map directly to product requirements like search-as-you-type, faceted PLP filtering, and "did you mean." Useful ammunition when arguing search deserves budget beyond LIKE %term%.
• Unit-economics modeling. Self-hosted Typesense vs. per-record Algolia pricing is a gross-margin lever at scale. A Scout-compatible driver keeps that lever movable, which matters for pricing and packaging decisions.
• Dependency risk triage. 1 star, 0 dependents, single maintainer, MIT: this is a prototype enabler, not a production foundation, unless you consciously accept ownership. That classification is itself a PM decision about where engineering time goes.

When to Consider This Package

Adopt/prototype when:

• You're on Laravel 12/13 + PHP 8.4/8.5 and you've verified that Laravel's own first-party Scout Typesense engine is unavailable, incompatible, or missing a capability you need. This is the gating question — Laravel ships a first-party Typesense driver, so the burden of proof is "what does this give me that the official one doesn't?"
• You need a specific fix or feature the official driver lacks and can't wait for upstream.
• You're running a time-boxed spike to evaluate Typesense relevance quality on your own corpus before committing.
• Your team is willing to fork and own it. MIT makes forking cheap; 0 dependents and 1 star mean you will become the de facto maintainer, so budget integration tests, version pinning, and a wrapped engine interface accordingly.

Look elsewhere when:

• The official Scout Typesense driver covers the use case. First-party code gets security review, docs, and guaranteed upgrade paths across Laravel majors — that's worth more than marginal feature delta.
• You need SLAs, vendor support, or compliance attestations → Typesense Cloud, Algolia, or Elastic.
• You're on Laravel ≤11 or PHP < 8.4 — compatibility is explicitly narrow.
• Search is a core differentiator with a dedicated team → go direct to the Typesense client to unlock curation, synonym sets, hybrid/vector search, and analytics that a Scout abstraction tends to hide.
• You have zero maintenance budget. A single-maintainer, zero-dependent package is a bus-factor liability you'd be introducing on purpose.

How to Pitch It (Stakeholders)

To executives: "This is a community driver that connects Laravel's search abstraction to Typesense, a self-hosted search engine with typo tolerance. It is not a strategic bet — it's a low-cost option that keeps our search backend portable. Recommendation: default to Laravel's first-party Typesense driver, which comes with maintenance and security guarantees this package does not. If we need Typesense-specific behavior the official driver lacks, we can spike on this in days, and because it's MIT-licensed, the worst case is we fork it. The real cost isn't licensing — it's the engineering time to own it, which we haven't allocated."

To engineering: "Adds a Scout engine so Model::search() hits Typesense on Laravel 12/13 / PHP 8.4–8.5. Before we adopt, diff its feature set against laravel/scout's built-in Typesense engine — that comparison is the decision. Maturity signals are thin: 1 star, 0 dependents, one maintainer, so treat it as unvetted. If we proceed: pin the version, hide the engine behind our own interface, and run integration tests against a local Typesense container so swapping back is a one-file change."