Laravel Searchzy Laravel Package

Product Decisions This Supports

• Feature scoping for list/table views. This package answers one narrow question: "how cheaply can we turn ?search=foo&status=active into an Eloquent query?" That's a recurring ask in admin panels, back-office CRUD screens, and internal tooling — not in customer-facing search.
• Build vs. buy (buy = adopt). The realistic comparison is three options: (a) adopt this package, (b) write a ~50-line local trait/scope, (c) adopt a heavier maintained alternative like spatie/laravel-query-builder or Laravel Scout. This package only wins if it's genuinely faster than (b) and you accept vendor risk.
• Search strategy tiering. Useful as the "tier 0" reference point in a roadmap discussion: LIKE-based filtering for internal tools, versus relevance-ranked search (Scout + Meilisearch/Typesense/Algolia) for anything a customer sees. Helps you avoid over-engineering internal screens and under-engineering customer search.
• Time-to-market estimates. If the package does what the description says, a filterable list endpoint drops from ~1 day of boilerplate to a few hours. That's a real, if small, schedule input for MVP/prototype planning.
• Dependency governance decisions. With 14 stars, a single maintainer, and no release since Feb 2021, this is a concrete case for your "do we accept unmaintained dependencies?" policy — useful as a precedent, not just as a tool.
• NOT a decision this supports: anything about search quality, ranking, typo tolerance, synonyms, faceting, analytics on search terms, or scale beyond what your database can LIKE scan.

When to Consider This Package

Consider it when all of these hold:

• You need simple filtering/matching on a handful of Eloquent models — query-string driven, LIKE/WHERE semantics, no ranking.
• The surface is internal (admin panel, ops tool, back-office) where search relevance and UX polish are not revenue-critical.
• Dataset is small-to-moderate (roughly under a few hundred thousand rows per table) and you're on MySQL/Postgres where LIKE '%term%' performance is acceptable.
• You're comfortable vendoring or forking — the code is small and MIT-licensed, so "adopt" can mean "copy into app/Support/ and own it" rather than "add a Composer dependency with a version constraint we can't patch."
• You want to skip writing the same boilerplate for the third or fourth time.

Look elsewhere when:

• You need relevance ranking, fuzzy matching, typo tolerance, synonyms, highlighting, or facets → Laravel Scout with Meilisearch/Typesense/Algolia. This package is not in that category.
• You need aggregations, complex boolean queries, or large-scale search → Elasticsearch/OpenSearch.
• You need active maintenance, security patching, or Laravel 11/12 compatibility guarantees. Last release was Feb 2021; a four-plus-year gap with 14 stars means you are effectively the maintainer. Check compatibility against your Laravel version before doing anything else — this is likely the deciding factor.
• You want a maintained, widely adopted equivalent → spatie/laravel-query-builder covers filtering/sorting/includes with a real release cadence and a large user base; the switching cost is a day, and the risk profile is dramatically better.
• You need public-API-grade filtering with strict allow-listing of filterable fields. Verify the package doesn't expose arbitrary columns before it touches anything user-facing; if you can't confirm, don't.

Default recommendation: treat this as a reference implementation, not a dependency. Read it, lift the pattern into a first-party trait you own, and move on.

How to Pitch It (Stakeholders)

To executives (one paragraph): Searchzy is a very small utility that saves engineering a day or two on internal admin screens by making it trivial to filter database records from a URL. It is not strategic, not customer-facing, and not a moat — it's commodity plumbing. Its risk is that it's been unmaintained since early 2021 with a single author and almost no adoption, so if we use it we should copy the pattern into our own codebase rather than depend on it. Recommendation: do not add it as a dependency; treat it as a design reference and budget a half-day to implement the equivalent ourselves. Net cost is roughly the same, net risk is materially lower.

To engineering (short): It's a LIKE-based filter sugar layer for Eloquent — no ranking, no index, no query engine. Last release Feb 2021, 14 stars, one maintainer, MIT. Before evaluating further, confirm it even installs on our Laravel version. If we want the capability, the honest options are (1) a ~50-line Filterable trait we own, or (2) spatie/laravel-query-builder if we want a maintained dependency with sorting/includes built in. If we ever need real search — relevance, typos, facets — that's a different product decision entirely (Scout + Meilisearch), and this package is not on that path.

One-line framing for the roadmap doc: "Simple filtering: build it, don't buy it. Real search: buy it, don't build it. Searchzy sits in the first bucket and doesn't survive the maintenance check."