Gally Standard Laravel Package

Product Decisions This Supports

• Build vs. buy for search merchandising. Gally is a full searchandising suite (indexing pipeline, rule engine, admin UI, API) rather than a library. The core decision it informs is whether to keep hand-rolling relevance logic — boosts, buries, synonyms, curations, redirects, zero-result handling — on top of Elasticsearch/OpenSearch, or adopt an opinionated suite that already models those concepts.
• Whether merchandising is a product surface or an engineering ticket. The strongest argument for Gally is organizational: it moves ranking and curation into a UI business users can operate, which is a product decision about who owns search quality, not just a tech choice.
• Roadmap sequencing for search relevance. If ranking work is repeatedly deprioritized behind feature work, adopting a suite converts an open-ended engineering backlog into an integration + operations line item with clearer scope.
• Scope of catalog complexity. It supports decisions around multi-store, multi-locale, and multi-channel catalogs, plus A/B testing of search strategies — relevant if you're expanding beyond a single storefront.
• Feature bets that depend on search quality. Recommendations, category pages, and conversion experiments are gated on relevance; Gally is a way to unblock those without building a relevance team first.
• Architecture stance: separate service vs. in-app package. Adopting it means committing to a standalone PHP/Symfony service behind an API, not a composer require inside a Laravel app. That shapes hosting, deploy topology, and on-call ownership — a decision worth making explicitly rather than by default.
• Not supported: this does not inform decisions about embedding search in an existing Laravel codebase as a first-class package. It is a Symfony-based application suite; integration is over HTTP, and any Laravel-side work is a client wrapper you own.

Diligence flags to resolve before this drives a decision: 6 stars, 0 dependents, and OSL-3.0 licensing. The release date metadata (2026-10-13) looks anomalous and should be verified against the actual repository tags. Low adoption signal means the "buy" case is really an "adopt and own" case.

When to Consider This Package

Consider it when:

• You have a catalog large enough that search relevance materially affects revenue (roughly thousands of SKUs and up), and search is a meaningful conversion path.
• Merchandisers or category managers are actively asking to tune ranking and can't get engineering time — the self-serve rule UI is the actual value.
• You already run (or are willing to run) Elasticsearch/OpenSearch and have PHP operational competence; adding a Symfony service is incremental rather than novel.
• You need multi-store, multi-language, or multi-channel catalog behavior that would be expensive to model yourself.
• You can treat it as a pilot or proof of concept with a defined evaluation window, not a core-platform commitment on day one.
• Legal has reviewed OSL-3.0. This is a copyleft-style license with an external deployment clause — if you expose modified Gally over a network, you may be obligated to publish those modifications. For a hosted SaaS this is a real constraint, not a formality.

Look elsewhere when:

• You need a Laravel-native package. Nothing here is drop-in; budget for a service, a client SDK, and ongoing ops.
• You're already standardized on a managed search product (Algolia, Typesense, Meilisearch) with merchandising features — switching cost likely exceeds the license savings.
• The catalog is small (hundreds of SKUs) and database-native search plus a handful of manual pins is sufficient.
• You require a commercial SLA, vendor support, security patching guarantees, or an active maintainer community. Six stars and zero dependents is a serious bus-factor signal; assume you may be maintaining a fork.
• Your team has no PHP/Symfony operational depth, or your platform strategy is deliberately non-PHP for new services.
• A network-copyleft license is incompatible with your distribution or hosted-product model and you cannot get an alternative license.

How to Pitch It (Stakeholders)

To executives: Gally is an open-source searchandising suite — it gives business teams direct control over how products rank in search and category pages, without filing engineering tickets for every boost or pin. It replaces either a commercial search-merchandising product or an internal relevance backlog. The license cost is zero, but the real cost is operational ownership: it runs as a separate service on top of Elasticsearch/OpenSearch. Adoption signal is currently thin, so the recommendation is a bounded pilot with clear success metrics (search conversion rate, zero-result rate, time-to-change for a merchandising rule) rather than a platform-wide commitment.

To engineering: Treat this as a service, not a dependency. It's PHP/Symfony, API-first, backed by Elasticsearch/OpenSearch — you'll deploy and operate it, write a thin client for our Laravel app, and own upgrades, index mapping changes, and reindexing runs. Key evaluation items: freshness of releases and commit activity, quality of the upgrade path between versions, the OSL-3.0 external-deployment clause for anything we modify and host, and whether the rule engine's data model fits our catalog attributes. If the pilot succeeds, plan for the possibility of forking and maintaining internally — price that in.

To merchandising/product ops: This is the tool that lets you change ranking yourself, preview the effect, and test strategies without waiting on a sprint. The pilot should be judged on how much manual engineering work it removes and whether the rules model your actual merchandising logic — not on installability.