Build vs Buy Enterprise Search: A Decision Guide for Mid-Size Catalogues
Building your own search costs more than it looks. Buying one can lock you in. What each choice really costs, a third option, and what to test before you decide.
Most build vs buy enterprise search decisions are made on the cost of the first version. The first version is the cheap part.
The short answer: for a mid-size catalogue (thousands to tens of thousands of items), building your own search only pays when search is part of what you sell and you can staff it permanently, because evaluation, vocabulary tuning, operations and telemetry never stop. Buying a SaaS search vendor is right when you need its features beyond retrieval and its relevance passes a test on your own catalogue. For most catalogue businesses the stronger option is a third one: a managed engine whose relevance is built from your catalogue's own words, run as SaaS or on your own infrastructure. Decide by testing all three on your own data, not by comparing feature lists.
For CTOs and heads of digital at publishers, distributors and B2B catalogue businesses: what each route costs, when each wins, a decision matrix and the tests to run before committing budget.
Why is this choice harder for search than for other software?
For most software, build vs buy is about features and cost. For search, it is about something neither a feature list nor a price sheet shows: whether the engine finds the right item when a person types the wrong words.
- Quality depends on your data, not the product. The same engine can be excellent on one catalogue and poor on another, because the hard part is your vocabulary: specialist terms, abbreviations, product codes and the way your users misspell them.
- Failure is silent. A search that returns nothing raises no error; the visitor leaves, and the business never sees the result the user did not get, as argued in why enterprise search is important.
- The work does not end at launch. Catalogues change, users find new ways to ask, and every fix risks breaking something that worked.
What are your three options?
| Route | What it means | Who owns relevance | Who runs it |
|---|---|---|---|
| Build in-house | Your team assembles an engine, usually on an open-source search library or a database's full-text index, and writes the indexing, ranking, front end and analytics | Your team | Your team |
| Buy a SaaS search vendor | You send your catalogue to a hosted search product and configure it through the vendor's dashboard and API | Shared: the vendor's general defaults, your configuration | The vendor |
| Managed, tuned engine | A specialist's engine that adapts to your catalogue's vocabulary, either self-serve as SaaS or deployed and tuned on your own infrastructure | Built from your catalogue's own words, with your test set as the gate | The specialist (SaaS), or deployed by the specialist on your infrastructure (on-premises) |
The difference between the second and third routes is not hosting. A self-serve managed engine is still a hosted product; what separates it from a general SaaS vendor is that relevance is built from your catalogue's words rather than general defaults — which is exactly what the tests below check.
What does building your own search really cost?
Building a working search box can take a competent team a few weeks. A build estimate usually stops there; the costs below arrive afterwards and never end.
1. Evaluation: knowing whether a change made search better
Without a test set, every relevance change is a guess. A useful harness generates realistic damaged queries (typos, reordered words, dropped words, abbreviations) for items you know exist, adds nonsense queries that must return nothing, replays your real failed searches, and is re-run on every change; the method is in a realistic dataset for comparing enterprise search solutions. Building it is a project; keeping it current is permanent work.
2. Vocabulary tuning: teaching the engine your catalogue's words
Out of the box, a search engine treats your catalogue as general language: a general dictionary "corrects" a valid technical term into a common word, two-letter abbreviations go missing, product names split at a hyphen. Each fix is small, but there are many, they interact, and each needs the evaluation harness to prove it broke nothing else.
3. Operations: running the index as a service
The index has to be rebuilt when the catalogue changes, monitored for latency, and kept available. Some changes are more expensive than they look: in Elasticsearch, the official documentation states that, apart from a few supported mapping parameters, you can't change the mapping or field type of an existing field, so the data has to be reindexed into a new index (Elastic, "Explicit mapping"), while synonyms are best applied at search time so they can be updated without reindexing (Elastic, "Configure synonyms"). Every engine has its own version of these trade-offs, and someone on your team has to know them.
Much of this is what Google's site reliability engineering book calls toil: manual, repetitive work that grows as the service grows (Google SRE book, "Eliminating Toil").
4. Telemetry: counting failure correctly
Logging queries is easy; counting them so the numbers mean something is not. A type-ahead box sends many requests per person, zero-result rates need counting per search intent, clicks need tying to the search that produced them, and your own test searches need excluding. How to measure enterprise search success sets out the measures and the traps. Without this layer, a built search cannot show it is working.
5. The front end and the edges
Type-ahead suggestions, a results page, an empty-results page that helps rather than dead-ends (Nielsen Norman Group on no-results pages), and protection for a public endpoint anyone can call.
| Cost line | One-off or recurring | What to put in the estimate |
|---|---|---|
| Engine, indexing, search API | Mostly one-off | Build time, plus upgrades of the underlying library |
| Evaluation harness | Build once, maintain forever | Time to build, plus time per change to run and extend |
| Vocabulary tuning | Recurring | Time per month to triage failed searches and fix them |
| Operations and on-call | Recurring | Infrastructure, monitoring, rebuilds, schema changes, incident time |
| Telemetry and reporting | Build once, maintain forever | Counting logic, dashboards, someone who reads them |
| Front end and public endpoint protection | Mostly one-off | Search box, results page, rate limiting, abuse handling |
| Key-person risk | Recurring | What happens when the one engineer who understands ranking leaves |
When building is the right answer
Build when search is part of the product you sell (a research database, a patent search service), when you need ranking logic no product supports, or when you already have people whose job is search. Then the recurring work above is the job, not a hidden cost.
What can go wrong when you buy a search product?
Hosted search vendors remove the operations burden and usually ship a good front end, analytics and merchandising tools. For many businesses that is the right trade. The risks are easy to miss in a demonstration.
Generic relevance
A vendor's typo tolerance, stemming and ranking defaults are designed to work across many customers' content. On a specialist catalogue, that is where failures come from: the engine "forgives" a valid technical term by matching a common word, or ranks a popular general item above the exact match. Most vendors let you change this; the question is whether your team will know which settings, and whether anyone will measure the effect.
A demonstration on exact titles will not reveal any of this. Every engine finds an exact title, so choose on misspelt, partial and abbreviated queries from your own catalogue.
Lock-in
Lock-in in search is rarely the data, which you can re-export. What does not move easily:
- Ranking rules and configuration built up in the vendor's dashboard, often with no export another engine can read.
- Analytics history, your record of what people failed to find.
- Front-end integration written against the vendor's widgets or client libraries.
- Usage-based pricing, so growth raises the bill on the vendor's terms.
None of these is a reason not to buy; they are reasons to ask what leaving would involve.
Data residency and query logs
When you buy, your index and query logs live in the vendor's infrastructure. The catalogue is usually public; the query logs are not, because people type names, email addresses and order numbers into search boxes, so a residency decision that only considers the catalogue is incomplete. For organisations subject to EU data protection law, transfers of personal data outside the EU rely on mechanisms such as adequacy decisions and standard contractual clauses, which the European Commission sets out on its international data protection page (European Commission, "International dimension of data protection"). Ask where the logs are kept, for how long, and whether you can choose the region.
When buying a SaaS vendor is the better choice
Buy when you need capability beyond retrieval: personalised ranking per visitor, merchandising workflows for a dedicated team, very large global query volumes or a large integration ecosystem. If the vendor's relevance passes your own test, its product depth will outweigh the lock-in.
When does managed search make sense?
In the third route a specialist's engine adapts to your catalogue's own vocabulary, and you keep control of the decision through your own test set. It suits the most common mid-size situation: search matters to revenue, nobody does search full time, and the vocabulary is specialist enough that general defaults will miss.
This is the route ITMTB works on. ITMTB deploys and tunes its own search engine in two ways:
- Self-serve SaaS on Tomorrow Central. Tomorrow Central Search takes a catalogue as a CSV, JSON or Google Merchant product feed file, or imports it from your website, and puts a search box, a hosted results page or results on your own page live on your site. Going live needs one proof that you own the website (a DNS record or a small file on the site); uploading and testing do not. It forgives misspellings by checking them against your own catalogue's words, not a general dictionary. You can pin or hide results for specific queries and compare results with and without your rules, and the statistics show searches, no-result searches and clicks. There is a free plan (at the time of writing: up to 5,000 products, 10,000 searches a month and one search project), so a catalogue of that size can be put through the tests below at no cost; searches you run while signed in do not count against the allowance. More in Tomorrow Central's guide to site search for a catalogue.
- On-premises through ITMTB. For organisations that need the engine inside their own infrastructure, for data residency, integration or scale reasons, ITMTB deploys and tunes the same engine there. Details are on the enterprise search page.
On one live catalogue, the same engine cut zero-result searches roughly tenfold (measured differently before and after; see the case study).
When a managed engine is not the right answer
If search is your product, build. If you need per-visitor personalisation or merchandising workflow tools, check whether the managed option covers them; a broad SaaS vendor may fit better. And a managed engine still needs an owner on your side who reads the no-result report every month.
Build, buy or managed: side by side
Score your situation against each row. The column matching most rows that matter to you is usually the answer; deciding factors can override the count.
| Criterion | Build in-house | Buy SaaS vendor | Managed, tuned engine |
|---|---|---|---|
| Search is part of what you sell (deciding factor) | Best fit | Weak fit | Weak fit |
| You have, or will hire, people whose job is search | Required | Helpful | Not required |
| Catalogue has specialist vocabulary, codes or abbreviations | Good, if staffed to tune it | Risky: test defaults on your data | Fits, if it passes your test |
| Catalogue size: thousands to tens of thousands of items | Overbuilt for most | Fits | Fits |
| Need per-visitor personalisation or merchandising team tools | Expensive to build | Best fit | Check before assuming |
| Index and query logs must stay in your infrastructure (deciding factor) | Fits | Depends on vendor regions and terms | Fits (on-premises) |
| Time to a live search box | Weeks to months | Days to weeks | An afternoon (self-serve, once your website is verified); on-premises is scoped with ITMTB |
| Recurring engineering effort | High and permanent | Low to medium (configuration) | Low (catalogue-specific correction is built in; you set pins and hides, or the specialist tunes on-premises) |
| Cost to leave | Low (you own it) but key-person risk | Medium to high (rules, analytics, integration) | Ask: what exports, and in what form |
| Who proves relevance improved | You, if you build the harness | You, if you build the harness | You, with your test set; on-premises, ITMTB can build and run it |
Three patterns cover most catalogue businesses:
- A research publisher or specialist B2B distributor with heavy vocabulary, no search team and a revenue-relevant search box: managed engine, SaaS if the data can leave, on-premises if not.
- A large retailer with a merchandising team, personalisation goals and high traffic: a SaaS vendor, chosen on a test on its own catalogue.
- A company whose product is search over a body of content: build, and staff it as a permanent team.
What to test before you decide
Run the same test on every option; a route that cannot be tested on your data before you commit is itself a finding.
| # | Test | Pass looks like |
|---|---|---|
| 1 | Export your catalogue: identifiers, titles, URLs and the fields people search by | Every option indexes the identical file |
| 2 | Pull a month of real queries and, separately, the ones that returned nothing | You have the list; if not, that is the first finding |
| 3 | Generate a known-item test set: misspelt, reordered, partial and abbreviated versions of items you know exist, as described in a realistic dataset for comparing enterprise search solutions | The intended item appears in the top five for most queries in every class, not just overall |
| 4 | Add nonsense queries that must return nothing | No results for invented words; a search that answers everything has hidden the zero |
| 5 | Replay your real failed searches | Searches whose answer exists in the catalogue now find it |
| 6 | Search for your own specialist terms correctly spelt | Valid terms are not "corrected" into common words |
| 7 | Ask how the option counts failed and zero-result searches | Counted per search intent, with your own test traffic excluded |
| 8 | Ask where the index and query logs are stored, for how long, and who can read them | An answer that meets your obligations, in writing |
| 9 | Ask what leaving looks like: catalogue, rules, analytics history | A clear list of what exports and in what form |
| 10 | Price year two, not year one: who tunes, who operates, who reads the reports. A build estimate covers months of construction; a licence fee covers years of operation | A named owner and an estimate for each recurring line |
A tool can win overall and lose the class your users hit most; compare per class, and see how to measure enterprise search success for the live measures once a search is running.
"AI search" is not a fourth route: meaning-based matching is a component any route can include, and because it tends to return something for every query, the nonsense test matters more. And whatever the route, name the person who will read the no-result report; without that owner, every route degrades.
Questions people ask
Should we build our own enterprise search?
Build only if search is part of what you sell, you can staff it permanently and no product fits your ranking needs, because evaluation, vocabulary tuning, operations and telemetry are permanent work that most build estimates leave out.
What are the hidden costs of building enterprise search in-house?
Four recurring ones: an evaluation harness re-run on every change, tuning to your catalogue's vocabulary, operating the index, and telemetry that counts failed searches correctly.
What are the risks of buying a SaaS search vendor?
Relevance tuned for general language rather than your catalogue's terms, lock-in through ranking rules and analytics history that do not export cleanly, and residency questions about the query logs, which can contain personal data.
What is managed enterprise search?
A middle route where a specialist's engine adapts to your catalogue's own vocabulary, either as self-serve SaaS, where it adapts automatically and you set the rules, or deployed and tuned by the specialist on your own infrastructure, so you get catalogue-specific relevance without staffing a search team.
Is in-house search cheaper than SaaS search?
Often in licence terms and often not in total cost, because a fair in-house estimate includes tuning, evaluation, on-call and telemetry for every year the search runs.
How do we compare build, buy and managed search fairly?
Run the same known-item test on every option, using your own catalogue and your real failed queries, on the same day and at the same result depth, and compare per query class.
When is buying a SaaS search vendor the better choice?
When you need capability beyond retrieval, such as per-visitor personalisation, merchandising team workflows or very high global volumes, and the vendor's relevance passes your own test.
Key takeaways
- The first version of an in-house search is the cheap part; the work around it is permanent, so build only when search is your product.
- Buying removes operations but brings generic relevance, lock-in and query-log residency questions; buy when you need more than retrieval and the vendor passes your test.
- A managed engine whose relevance comes from your catalogue's own words, as SaaS or on-premises, fits most mid-size catalogues with specialist vocabulary and no search team.
- Decide on a known-item test run on your own catalogue and real failed queries, compared per class, and price the second year of every route.
Where to start
To run the test on a tuned engine without an engagement, sign up for Tomorrow Central Search on the free plan (or a 5,000-item sample if your catalogue is larger), upload your catalogue and use the signed-in Try-it search before anything goes live; Tomorrow Central's guide to adding search to a website walks through the steps. If the engine needs to run inside your own infrastructure, or you want ITMTB to build the test set from your catalogue and run it against your current search before you decide, see enterprise search or contact us.
Sources
- Elastic, "Explicit mapping", Elasticsearch documentation, accessed 19 October 2026: https://www.elastic.co/docs/manage-data/data-store/mapping/explicit-mapping
- Elastic, "Configure synonyms", Elasticsearch documentation, accessed 19 October 2026: https://www.elastic.co/docs/solutions/search/full-text/search-with-synonyms
- Google, Site Reliability Engineering, chapter "Eliminating Toil", accessed 19 October 2026: https://sre.google/sre-book/eliminating-toil/
- Kathryn Whitenton, "3 Guidelines for Search Engine 'No Results' Pages", Nielsen Norman Group, 5 January 2014, accessed 19 October 2026: https://www.nngroup.com/articles/search-no-results-serp/
- European Commission, "International dimension of data protection", accessed 19 October 2026: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection_en
- ITMTB enterprise search case study: /blog/enterprise-search-case-study-business-research-company
Deciding how to get search right for your catalogue?
ITMTB runs the same test on every option you are considering, using your own catalogue and your real failed searches, so the decision rests on results rather than demos. Self-serve on Tomorrow Central, or on-premises.
