Product Decisions This Supports
- Whether to ship instant, as-you-type search at all. The package is a working reference for the "type three characters, see results in under 200ms" pattern on a Statamic content site. It helps frame the decision as a UX investment (search abandonment, content findability, time-to-answer) rather than a pure infrastructure line item.
- Build vs. buy for search. It represents the "build" pole of the spectrum: a local, Livewire-driven search over Statamic's own index, no Algolia/Typesense/Meilisearch subscription, no data leaving the app. Comparing it against a hosted search vendor is a concrete way to price the tradeoff — engineering hours and ongoing ownership versus monthly cost and vendor lock-in.
- Whether search is a differentiator on the roadmap or table stakes. If search is a headline feature for a content-heavy property, the package's simplicity is a liability and the roadmap should fund relevance tuning, faceting, and analytics. If search just needs to exist and be "good enough," this is a credible shape for the feature.
- Scope of a search MVP. It bounds the effort for a first release to a component plus a query layer, which is useful for sizing a spike or a one-sprint experiment before committing to a larger search programme.
- Dependency posture for the platform. Because the package is archived, it forces an explicit decision on the maintenance axis: is search core-path (own it, vendor it, or buy it) or peripheral (tolerate a frozen dependency)?
When to Consider This Package
Consider it when all of the following hold:
- The product runs on Statamic and the team is already comfortable with Livewire in the front end.
- The content set is modest — roughly low thousands of entries at most — where a straightforward query against Statamic's index returns fast enough without a dedicated search engine.
- The requirement is single-locale, single-collection or lightly faceted instant search with no need for synonyms, typo tolerance tuning, relevance ranking controls, merchandising, or search analytics.
- There is no appetite for an external search service — cost, procurement, data residency, or GDPR/DPA review make SaaS search unattractive.
- The team is willing to treat the code as a reference implementation and own it: fork it, read it, or reimplement the pattern in-house, rather than adding an archived package as a tracked dependency.
Look elsewhere when:
- You need a maintained dependency. The repository is archived and sits at 22 stars. There is no security patching, no compatibility guarantee against future Statamic or Livewire majors, and no upstream to escalate bugs to. That is disqualifying for anything on a critical path with an availability or support expectation.
- Search quality is a product requirement, not a checkbox. Relevance tuning, faceted filtering, fuzzy matching, and zero-result recovery are exactly where hosted engines (Algolia, Meilisearch, Typesense) earn their cost, and where a thin Livewire wrapper will not carry you.
- The content corpus is large or grows quickly, or search is expected to handle media, PDFs, or cross-property federation.
- You are not on Statamic, or not on Livewire — the value proposition collapses entirely.
- Search needs to be measured. There is no built-in analytics, so you cannot answer "what do users search for and fail to find?" without additional instrumentation you would have to build anyway.
How to Pitch It (Stakeholders)
For executives (one line): A small open-source Statamic add-on that shows how to add instant search to a content site in about a sprint's worth of work with no vendor subscription — but it is archived and unmaintained, so we should use it as a blueprint rather than a dependency, and only pursue it if search is table stakes rather than a differentiator.
For engineering: This is a compact, readable implementation of Livewire-driven live search over Statamic's index. Treat it as a pattern library, not a package. The realistic play is a spike: clone it, port the component and query approach into our own codebase, and own the result — roughly a component, a debounced input, and a result partial. Doing so gives us full control over relevance, escaping, caching, and future extension, and removes the risk of shipping an archived third-party artifact into a user-facing path. If we adopt the code directly, we should pin it, vendor it, and accept that we are the maintainers from day one.
For the roadmap decision: Fund a short evaluation spike against a hosted search option before committing. The spike answers two questions cheaply — does local search feel good enough on our actual corpus, and what does the hosted alternative cost per month versus the engineering ownership we would take on? If the answer is "local is fine," build it ourselves from this pattern. If search is expected to drive conversion or retention, buy the engine and spend our engineers on the experience around it rather than on the index.