The estimate is always low
Search gets scoped as one field and a database query, and then discovers everything the field implies: partial matches, misspellings, synonyms, ranking, permissions, and what to show when there are no results.
Matching is the easy part; ranking is the product
Finding rows containing a word is trivial. Deciding which five of two hundred matches go at the top is the entire user experience, and it requires knowing what users are usually looking for — which you learn by logging queries, not by guessing.
Nobody complains that search returned too few results. They complain the right one wasn’t near the top.
Design the empty state first
No results is the moment a user decides whether search works. Suggesting corrections, relaxing filters, or offering the nearest alternatives turns a dead end into a recovery — the same principle as error messages that say what to do.
Permissions belong in the query
Search that returns titles a user may not open leaks information through the result list itself. Filtering must happen during retrieval, exactly as it must for an AI feature reading your documents.
Queries are the cheapest research you own
What people search for, and what returns nothing, tells you what your product or documentation is missing. It is the same signal as the questions an AI feature couldn’t answer, and almost nobody reads either.
Buy before you build
Search is a well-solved problem with mature components. Writing your own ranking is a research project disguised as a feature, and one of the clearest cases where buying beats building.