Build your own search engine or buy one: how to decide

The question being asked is rarely the right one

"How much would it cost to build it ourselves?" almost always gets the same answer: Elasticsearch is free, an in-house developer already costs what they cost, and the rest seems like just a matter of time. On paper, building looks cheaper than buying.

The right question isn't "how much does version 1 cost to build" — it's "how much does it cost to maintain at version 40, two years from now, once the person who wrote it is gone." That's where the calculation almost always tips the other way.

What "building" actually means

A search engine for a technical catalog isn't installing Elasticsearch and firing off a match query. At minimum, it's:

Tokenization that distinguishes a reference from an everyday word — without it, "M8x20" gets split into three unrelated words. Typo tolerance calibrated by token type — a typo on a numeric reference shouldn't behave like a typo on a product name. Managing synonyms and business rules by industry. Ranking that prioritizes stock without overriding relevance. And, as soon as a second customer or a second reference language comes along, maintaining all of that over time.

None of this is exotic. But each piece, taken separately, takes a competent developer one to three weeks — and they interact with each other, which means the third piece sometimes breaks the first.

The real cost of "building" isn't the first version. It's the developer who has to remember, six months later, why a given regex exists — while they should be working on something other than search.

What "buying" avoids, precisely

A specialized search engine doesn't buy a feature, it buys a problem already solved by someone whose full-time job it is — not a side task on a product developer's list. The difference shows up on three points: edge cases already encountered (the typographic "×" copied from a PDF, the decimal comma in "2.5 mm²," the many ways to write the same reference), maintenance that follows version upgrades without pulling in your team, and time to launch — days rather than months before the first usable result.

When building it yourself is genuinely justified

It's not always the wrong choice. Building makes sense when search IS the product — a generalist search engine, not an engine in service of a catalog. When volume justifies a full-time dedicated team, not a side task. Or when your reference structure is so specific that no solution on the market, generalist or specialized, can cover it without a full rewrite.

Outside those three cases, the question is simple: is search what differentiates your business in your customers' eyes, or is it a means of reaching what actually differentiates your business — your catalog, your product expertise, your customer relationship? If it's the second answer, every week spent on the engine is a week not spent on what matters.

Where Heurix sits on this trade-off

Heurix doesn't claim to replace a generalist engine on its own turf — a fashion catalog or editorial content does perfectly well with Algolia or Meilisearch. Its place is narrower: catalogs where the reference itself carries technical information, and where that information varies by industry.

Concretely, that means business rules already written by industry — hardware, industry, electronics, fashion, books, wine — rather than written one by one. Ranking that combines relevance and stock availability with no extra configuration. And one simple principle running through the whole product: the merchant keeps control of their rules, nothing is decided for them opaquely.

The concrete result: a catalog already exported can be tested in an afternoon, and going live on PrestaShop or WooCommerce takes two to four days — not months of in-house development to reach the same point.

How to decide, without ideology

Three questions are usually enough. Will a developer spend more time on search than on what actually differentiates your business? If the person building the engine left tomorrow, could someone else pick up the code in a day? And does the catalog have a reference structure specific enough to justify a custom solution rather than a tool already built for the case?

If the answers lean "no," the most honest calculation isn't build versus buy — it's your technical team's time invested elsewhere, against a subscription starting at €19/month.