Build vs Buy: Managed Search Platforms vs a Custom Semantic Search Stack

Not a two-way choice

Build vs buy for semantic search usually gets posed as "licence a managed search platform or build our own." There's a middle option most mid-market catalogues land on: a custom stack assembled from managed components — an embedding API, a vector extension on the database you already run, a managed re-ranker, and your own merchandising console — without owning GPU inference or starting from scratch.

Option 1: buy a managed search platform

Fast to integrate, handles indexing and ranking infrastructure, and relevance is good out of the box.

What it costs you:

• Pricing that scales with the catalogue. Managed platforms typically bill on some mix of search requests and records, and AI-relevance features often sit on a higher tier than plain search — a line that grows with catalogue size and query volume rather than flattening once you're set up.
• Generative recommendations as a bolt-on. Grounded natural-language recommendations are usually a separate layer that still calls an external model.
• Their ranking model. You tune within the surface they expose; the decision logic is theirs.

Option 2: build fully in-house

Own the embedding infrastructure — self-hosted models and GPU — plus the vector store, the re-ranking, the sync pipeline, and the console. A multi-quarter project with real MLOps ownership, justified only if search is close to core and you have the team to keep it alive.

Option 3: a custom stack on managed components

A managed embedding API (no GPU to run), a vector extension on your existing database, a managed re-ranker, and a merchandising console you control. This is the shape of our semantic search project: the team weighed a managed platform and a self-hosted search engine against a custom retrieval service on a vector-extended database, and built the custom stack in an eight-week window — because owning the retrieve-rank-generate chain was cheaper in total and gave the client the generative layer a platform would have charged for as a black box.

Signals you've outgrown "buy"

• Per-request and per-record pricing at your catalogue size and query volume is a big, forecastable line.
• You want the retrieve-rank-generate chain under your control — prompt, cost per generation call, ranking logic — not a black-box AI tier.
• Merchandising needs control — boost, bury, filter as data with no redeploy — beyond what the platform's model exposes.
• A supplier feed churning thousands of SKUs a week, and you want the sync logic to be yours.

Where "buy" stays the right answer

• A smaller or stable catalogue where per-request pricing never bites.
• A team that wants zero search infrastructure to own.
• Standard relevance needs with no appetite for running a re-embedding pipeline.

A quick way to place yourself

1. Does per-request plus per-record pricing hurt at your catalogue size and query volume? Yes pushes toward custom.
2. Do you need generative recommendations, or just ranked results? Generative under your control pushes toward custom.
3. Do you have database and ops capacity for a vector extension and a re-embedding worker?
4. How much merchandising control do you need without an engineering deploy?

Run the numbers before you decide

This gets decided on a demo and a gut feel more often than it should. It's a spreadsheet. On the buy side: the platform's quote at your current record count and query volume, then again at 2x and 5x, including the AI-relevance tier. On the build side: the one-time build (embedding pipeline, the retrieve-rank service, the merchandising console, an eval set), plus the recurring run cost (an embedding call and a re-rank call per search, the vector store, and the re-embedding worker), amortised over two to three years. If the platform is cheaper at every volume you can foresee and its relevance and merchandising controls fit, the decision is made. Building enters the picture when the pricing curve or the control gap makes "good enough for most catalogues" not good enough for yours.

Where this stops being right

• A small, stable catalogue — buy, or even keyword search plus a synonym list.
• No ops capacity — a managed platform is maintained for you; a custom stack you can't staff decays.
• Multi-million vectors or query volume past one database instance — that's a dedicated vector database conversation whichever way you went.

FAQ

Is a managed platform just a stopgap? No — for many catalogues it's the right permanent answer. Building is a response to pricing at scale and control needs, not a maturity milestone.

Can we start managed and move later? Yes, and it's common. Run the platform, instrument what it can't tune, and scope a custom stack for the gap.

What's the long pole in a custom build? Not the model — the sync pipeline that keeps the index fresh against the supplier feed, and the merchandising console.

ISTRALLEN builds custom semantic search stacks on managed components for retail catalogues that have outgrown platform pricing; see AI for Retail.