Ecosystem Laravel Package

Product Decisions This Supports

• Build vs. buy for search: this package is the "no search server" option on the spectrum between raw WHERE LIKE queries and standing up Meilisearch/Typesense/Elasticsearch. It makes the case for deferring search infrastructure spend until relevance quality or scale demonstrably fails.
• Roadmap sequencing: if deep relational search (nested relations, JSON columns, cross-model results) sits on the roadmap, this can ship it in days rather than the multi-sprint cost of a search backend plus indexing pipeline plus sync/backfill jobs.
• Feature scope for admin and internal tooling: global multi-model search with highlighting maps directly to internal dashboards, support consoles, and CMS back offices — features that are high value but rarely justify dedicated infrastructure.
• Search syntax as a product surface: phrases, exclusions, field filters, and ranges are the vocabulary of power-user search. This enables a documented query syntax for power users without building a parser, and it is a genuine differentiator versus basic Eloquent filtering.
• Reduced operational surface: no index sync, no reindex jobs, no dual-write consistency bugs, no additional service in the on-call rotation. This is a real, quantifiable ops-cost argument in roadmap prioritization.
• Data residency and compliance positioning: search runs against your existing database, so no third party or secondary store holds a copy of user data. Useful for regulated or privacy-sensitive products where sending records to an external index is a review burden.
• Maturity signal: v1.0.0 is the first stable release. That supports a pilot or a bounded internal-tool deployment, not a core-product dependency, until you have your own evidence.

When to Consider This Package

Adopt when most of the following hold:

• Stack fit: PHP 8.3+ and Laravel 11 or 12. This is a hard gate — it excludes LTS-bound or older-runtime estates immediately.
• Dataset profile: your searchable data lives in MySQL/Postgres and is of a size where database-side filtering and ranking remain acceptable. Small-to-mid tables, or queries that are already well-indexed, are the sweet spot.
• Query shape: you genuinely need relation-depth traversal or JSON-path search. If your search is single-table with a couple of columns, native Eloquent/whereFullText is simpler and you should not add a dependency.
• Freshness requirement: results must reflect writes immediately. Search-server architectures introduce indexing lag and sync complexity; this avoids both.
• Modest relevance needs: you want ranked, filtered, highlighted results — not semantic search, typo tolerance, faceting at scale, or per-field boosting tuned by an ML loop.
• Willingness to own the SQL: you accept that relevance tuning means tuning generated SQL and indexes, and that your DBA/engineering team will own query-plan review.

Look elsewhere when:

• Scale or latency is a hard SLA. No benchmark data was supplied with this release. Until you measure p95 latency on production-shaped data at your expected row counts and relation depths, treat performance as unproven. Deep relation joins plus ranking are where database-side search typically degrades first.
• You need typo tolerance, synonyms, semantic/vector search, or rich faceting. That is search-server territory.
• You need a vendor with a support contract. This is a first stable release from a single-author-style package (atannex); assess bus factor and maintenance cadence before betting a customer-facing surface on it.
• You need upgrade certainty. PHP 8.3+/Laravel 11–12 only, with a 1.0.0 that has no track record of major-version migrations. Budget for the possibility that you pin a version for a long time.
• Search is your product's core differentiator. If relevance quality is the product, buy or build a dedicated engine and accept the operational cost.

How to Pitch It (Stakeholders)

For executives — one line: a mature, zero-infrastructure search capability for our Laravel application that ships relational and cross-model search without buying, hosting, or operating a search service.

The business case: search infrastructure is a fixed cost — a service to run, an indexing pipeline to build, and permanent sync/consistency work. This package removes that entire cost line for the common case by searching the database we already operate. It also keeps data in our existing store, which simplifies privacy and data-residency review.

What it buys us: faster time-to-market on search-dependent features (admin consoles, internal tools, power-user search syntax with filters, ranges, phrases, and exclusions), and highlighting and cross-model results out of the box — work that would otherwise be estimated in weeks.

The honest caveats, stated plainly: this is the first stable release, so there is no production track record, no published benchmarks, and no support contract. It requires PHP 8.3+ and Laravel 11–12, so it is not available to every service we run. And it does not replace a real search engine for typo tolerance, semantic relevance, or high-scale faceting.

Recommendation for engineering: approve as a contained pilot — start with internal tooling or an admin surface where failure is low-blast-radius. Success criteria before wider adoption: measured p95 latency on production-shaped data, a documented supported query subset, and a written exit path (the query layer should be behind our own abstraction so swapping in a search server later is a contained change, not a rewrite). Treat the dependency as pinned and audited, not assumed-maintained.