Scolta Php Laravel Package

Product Decisions This Supports

• Build vs. buy for site search. This package is the PHP-side entry point to an embedded search engine (Scolta core compiled to WebAssembly, invoked through the Extism PHP SDK). It reframes search from "procure a hosted service" to "ship a dependency," which is the core decision to make.
• Feature scoping for search relevance. If we invest here, we own relevance tuning, indexing pipelines, and query behavior in-house rather than consuming a vendor's API surface. That is a product commitment, not a library choice.
• Roadmap sequencing for a Laravel (or Drupal/WordPress) search initiative. The binding itself delivers no user-facing capability; it is an enabling dependency. It should appear on the roadmap only as a line item inside a larger "search experience" epic with its own success metrics (zero-result rate, click-through on results, search-to-conversion).
• Total cost of ownership modeling. No license fee (MIT), no per-query billing, no cluster to operate — versus engineering hours to integrate, tune, and support an immature ecosystem. This is the trade a PM needs quantified before approval.
• Differential/privacy positioning. Self-hosted, in-process search keeps indexed content and query logs inside our infrastructure — relevant if we sell to customers with data-residency or "no third-party SaaS" requirements.
• Architecture bets worth a spike, not a roadmap slot. With 3 stars and 0 dependent packages, this is an evaluation candidate. The PM decision is to fund a time-boxed spike with explicit kill criteria, not to commit a release.

When to Consider This Package

Adopt for evaluation when all of these hold:

• We have already chosen (or are seriously testing) Scolta as the engine; this package is only a transport/binding layer and has no independent value.
• The target application is PHP — Laravel first, with Drupal/WordPress as secondary — and we want search embedded in the app rather than as a separate service.
• We can run the Extism PHP extension/FFI/WASM path in our hosting environment. Serverless PHP, restrictive shared hosting, or hardened containers that block native extensions are disqualifying until proven otherwise.
• We can tolerate a pre-adoption ecosystem: pin an exact version, expect breaking changes, and can vendor or fork if the upstream stalls.
• Search volume and corpus size are modest enough that in-process WASM execution has a plausible performance story; we will benchmark before committing.
• We need the privacy/offline/no-SaaS property specifically, or we are optimizing for near-zero marginal cost per query.

Look elsewhere when:

• Search is a top-three user journey and needs proven relevance, faceting depth, synonyms, analytics, and A/B tooling on day one. Evaluate Laravel Scout with Meilisearch/Typesense, or a managed service such as Algolia.
• We need an SLA, vendor support, security review artifacts, or a documented upgrade path — none of which a 3-star, zero-dependent package can supply.
• We need high-write-throughput indexing (large catalogs, frequent re-index) or very low-latency queries at scale; the WASM boundary needs measurement first.
• The team has no appetite to own debugging at the WebAssembly↔PHP boundary. That is a niche skill and a real support burden.
• The Laravel adapter referenced in the description is not yet at parity with the Drupal/WordPress ones. Verify feature coverage per platform before scoping — a binding with no first-class Laravel integration means we write the adapter ourselves.

How to Pitch It (Stakeholders)

To executives (one paragraph): We are evaluating Scolta, an open-source search engine (MIT) that runs inside our PHP application instead of as a separate hosted service. The practical upside is cost and control: no per-query fees, no search cluster to operate, and customer content never leaves our infrastructure — which helps with data-residency objections in enterprise deals. The practical risk is maturity: the PHP binding is a very early project with negligible adoption today, so we are proposing a short, time-boxed technical spike with defined success and kill criteria, not a commitment to ship. If the spike passes, we get a differentiated, low-marginal-cost search capability we fully own; if it fails, we lose a few engineer-weeks and default to a proven managed search provider.

To engineering (the ask and the guardrails):

• Scope: prove the full path — index a representative corpus, run representative queries, measure p50/p95 latency and memory inside the PHP process, and confirm it works in our actual deployment target (including any serverless or container constraints).
• Deliverables: a working Laravel integration prototype, a benchmark table against our current search baseline, and a written assessment of the extension/WASM runtime risk in production.
• Guardrails: pin the exact version, do not introduce it as a transitive dependency, do not expose it in a customer-facing path before the spike passes, and keep the integration behind an interface so we can swap the engine without touching product code.
• Non-goals for the spike: relevance tuning at scale, analytics, multi-tenant isolation, and operational runbooks. Those are post-decision costs and should be estimated separately.

Bottom line for the decision log: low lock-in, low direct cost, high ecosystem risk. Fund the spike; do not put it on the release roadmap until the benchmark and runtime findings land.