Xumulus Logo
Large-catalog commerce · search · discovery

Search & commerce
infrastructure you control

query: relevance

We help retailers with large, technical catalogs improve product discovery, migrate platforms, and connect PIM, ERP, search, and storefront systems — without sacrificing speed or control.

Request a discovery auditSee client resultsNext.js · Elastic/OpenSearch · RAG
Strategy
Roadmaps & search audits on real data.
Migrations
Clean cutovers, no lost revenue.
Integrations
ERP, PIM, OMS, search wired together.
Managed
Ongoing platform & search ops.
Selected outcomes

Complex catalogs. Measurable results.

Read the case studies →
7–8s → 1–2s
Page loads
National Tire & Wheel
2×+
Conversion rate
After replatforming
4–5s → <400ms
Product pages
Moon Audio
20 years
Enterprise delivery
Commerce, search & CMS

Own the discovery layer — not another plugin stack.

Bring catalog data, fitment, content, behavioral signals, and merchandising rules into one model serving search, category pages, product pages, and AI experiences.

Elastic
Relevance + speed
Next.js
Modern UX + performance
RAG
Agentic discovery ready
Questions the model can answer
Will this fit my vehicle?
What can ship today?
Which option is best for this use case?

Answers grounded in current catalog facts, compatibility data, availability, and merchandising rules — not a disconnected AI widget.

Why the status quo fails

One catalog update. Two customer answers.

Bolt a search plugin onto Shopify — Algolia, Searchspring, Klevu, Searchanise, Boost — and you haven't added one integration; you've added a sync chain. The plugin's index is a copy, not the record, so data has to hop across sync boundaries to reach it: into Shopify, shipped out to the indexer, augmented by a side process for the data the platform can't hold natively, and finally into the plugin's index. Every hop is a place to lag or break.

The alternative is an owned discovery model built directly from the systems that are authoritative for product content, price, inventory, fitment, and behavior. Search, browse, product pages, merchandising, and AI experiences use that same serving model. The transactional systems remain authoritative; the fragmented plugin copies disappear. That is an architectural change, not a tuning win.

Same shape inAlgoliasearch APISearchspringmerchandisingKlevuAI discoverySearchanisemulti-platformBoostfilters
What the lag looks like to a shopper

A product's price drops from $10.99 to $9.99 and it sells out — one change to the record. The product page reads the platform, so it shows $9.99 · out of stock right away. Search, autocomplete, and the category pages read the index, which hasn't caught up — so they still show $10.99 · in stock. Same product, same second, two answers. That gap isn't a bug to be fixed; it's the width of the sync window, and the window is always open.

Before — the plugin's index is a copy, so it lags the record
the same architecture in every plugin in the category
record updated → $9.99 · out of stock
Your catalog data
source
sync
Shopify / BigCommerce
the record · price · stock
ship · lag
Indexer intake
the plugin pulls the platform API + webhooks
index
The plugin's index
Algolia · Searchspring · Klevu — a copy, not the record
Augments the intake
Fitment matrices, spec PDFs, rich HTML — forced into Shopify metafields and metaobjects where they fit, and into a separate feed where they don't.
Three sync boundaries before the index catches up.
Reads the index
Search$10.99 · in stock
Autocomplete$10.99 · in stock
Category pages$10.99 · in stock
Reads the platform
Product page (PDP)$9.99 · out of stock
Checkoutplatform-supplied
The fault line

The shopper filters to an in-stock item at one price and lands on a page telling them it's gone at another. Search and category render as client-side JavaScript injected into the theme; the product page never moved. The split shows up in configuration too — on the leading integration, search-page facets and category-page facets live in separate configs that don't sync — and some updates never arrive at all, since a variant-level metafield change doesn't fire the product-update webhook the plugin relies on. None of this is misconfiguration; it's the architecture working as designed.

Architecture confirmed against Algolia's published Shopify documentation — the reference implementation for the category. Searchspring, Klevu, Searchanise and Boost follow the same shape. All five run on Shopify; Boost is Shopify-only.

After — one owned discovery model serves every customer surface
authoritative inputs · one pipeline · one current answer
update → $9.99 · out of stock
Platform · price · stock
Enrichment · fitment · docs
Metrics · revenue · margin
one pipeline
Owned discovery model
canonical serving layer · enriched · server-rendered · crawler-safe
Search$9.99 · OOS
Autocomplete$9.99 · OOS
Category pages$9.99 · OOS
Product page$9.99 · OOS
CMS pagesin sync

One authoritative update → every discovery surface shows $9.99 · out of stock, near-instantly.

Cart and checkout can be our own, custom, or wedged into Shopify or BigCommerce — the catalog doesn't depend on it either way.
Bottom line

Every plugin in the category — Algolia, Searchspring, Klevu, Searchanise, Boost — asks the merchant to operate a second discovery model inside someone else's product and keep it synchronized forever. The owned-model approach creates one governed ingest and one serving layer for every discovery surface, while ERP, PIM, commerce, and operational systems remain authoritative for the facts they own.

Stop tuning the copies. Own the model that powers discovery.

Discovery bottlenecks

A modern, platform-less foundation for agentic commerce•

SaaS commerce platforms are proven and convenient. But as brands grow, catalog complexity increases, and competition shifts toward the new AI era, many teams get handcuffed by their platform:

01
Keyword-based search fails shopper intent
Platform-native search breaks down as catalogs scale and buying journeys become discovery-driven.
02
Filtering and merchandising controls are constrained
High-SKU catalogs require enterprise-grade retrieval and ranking logic beyond standard SaaS platform capabilities.
03
App-layer complexity slows performance
As feature demands grow, third-party app stacks increase latency, cost, and maintenance burden.
04
AI features remain surface-level widgets
Without an owned retrieval foundation, agentic commerce workflows are difficult to implement.
Key takeaway
At enterprise scale, discovery is no longer UX — discovery is infrastructure.

Built on 20 Years of Enterprise Experience

For the past two decades, we’ve delivered large-scale e-commerce and enterprise CMS systems — long before the term “headless commerce” existed. 2 truths and a lie! Truth: You need a modern web stack to compete. We advocate for Next.js. Truth: You need a tremendously flexible, scalable, and performant backend based on systems capable of semantic and vector searching and RAG, to process all available AI signals. Lie: The leading e-commerce platforms can provide this. Search engines drive these features, so we build on top of that. Keeping it simple and eliminating many API layers.

— Daniel Kozlowski
Founder · Enterprise Commerce Architect
The stack

The AI Discovery Stack for Modern Commerce•

We build the retrieval and storefront foundation brands need to compete on search-led conversion and AI-native shopping journeys.

01
1) Storefront

Next.js Performance Storefront Layer

High-performance, AEO-first storefront architecture built for scale — with full flexibility beyond themes and app constraints.

  • Sub-second storefront performance
  • Composable UX journeys
  • Modern frontend longevity
  • AI Guided adaptations
02
2) Retrieval

ElasticSearch Discovery & Merchandising Engine

Enterprise-grade retrieval, ranking control, and high-SKU filtering. Search becomes a conversion system — not a utility box.

  • Hybrid keyword + semantic search
  • Advanced facets + filtering at scale
  • Merchandising-driven relevance tuning
  • Automagic Variants
03
3) AI Foundation

Agent-Ready RAG Foundations

Vector + metadata retrieval pipelines that enable conversational discovery, guided selling workflows, and future agentic commerce automation.

  • RAG-ready product knowledge retrieval
  • Conversational shopping experiences
  • Autonomous merchandising foundations
  • Extndable Signal Sources (sales, customer service, web analytics ...)
Contrast

Platform Extensions vs Discovery Ownership•

Most commerce agencies optimize within platform boundaries. We build beyond them — so you own discovery, retrieval, and AI readiness.

01
Comparison
Traditional SaaS / API-First Commerce
App-driven feature stacking
AI Discovery Infrastructure Approach
Owned architectural control
02
Comparison
Traditional SaaS / API-First Commerce
Theme-level customization
AI Discovery Infrastructure Approach
Next.js composable experiences
03
Comparison
Traditional SaaS / API-First Commerce
Platform-native search limitations
AI Discovery Infrastructure Approach
Elastic-powered retrieval engine
04
Comparison
Traditional SaaS / API-First Commerce
Widget-based AI add-ons
AI Discovery Infrastructure Approach
Agent-ready RAG foundations
05
Comparison
Traditional SaaS / API-First Commerce
Platform constraints
AI Discovery Infrastructure Approach
Full discovery ownership
Bottom line
SaaS platforms run transactions. We build the intelligence layer that drives discovery.
Search & Discovery Audit

Start with a Search & Discovery Audit•

A two-week technical assessment that quantifies discovery upside and delivers a prioritized roadmap for Elastic/OpenSearch-powered retrieval, Next.js performance, and agent-ready foundations.

Relevance + UX diagnostics
Core Web Vitals + performance benchmark
ElasticSearch opportunity blueprint

Build the AI Discovery Infrastructure SaaS Platforms Can't Provide Natively

The future of ecommerce will be search-led, AI-driven, and agent-powered. Let’s architect the retrieval foundation that enables it.

Search is the foundation of AI commerce