Go to any SaaS app you use daily. Click the search bar. Type something slightly outside the exact phrasing of a menu item or document title. See what happens.
Nine times out of ten, you'll get nothing useful. Maybe a "no results found" page. Maybe results sorted by creation date instead of relevance. Maybe a list of every record that contains one of the three words you typed.
This happens on products built by teams of 50+ engineers with millions in funding. The search bar is right there in the UI. It just doesn't work.
The Numbers Are Bad
Search users are not casual browsers. They're the people who showed up knowing what they want.
- 68% of users go straight to the search bar when they land on a site
- Search users convert at 2-3x the rate of non-search users
- Only 15% of visitors use site search, but they generate 45% of total revenue
- Amazon's conversion rate jumps from 2% to 12% when search is used
And the other side:
- 80% of users leave because the search results are bad
- 81% of sites return irrelevant results for simple two-word queries
- U.S. retailers alone lose roughly $300 billion per year to poor search
That last number sounds made up. It's not. When your highest-intent users hit a dead end, they don't try rephrasing. They leave.
How Search Actually Gets Built
Nobody sets out to build bad search. It just kind of happens.
A product launches with no search. Users ask for it. Someone adds WHERE title ILIKE '%query%', maybe with some ts_vector if they're feeling ambitious. It ships. It technically works.
Six months later, the data has grown. Results get worse. Users complain. The team acknowledges it's a problem but nobody prioritizes it because search isn't a feature anyone owns. It's nobody's OKR. It doesn't have a PM. It falls into the gap between product, engineering, and data, and it stays there.
A year in, somebody suggests Elasticsearch. Two weeks of setup, ongoing tuning nobody wants to do, and eventually it's "good enough" and the team moves on.
Search is a horizontal feature. It touches everything but lives in no team's roadmap.
Why Keyword Search Breaks Down
Most product search is still keyword matching. And keyword matching can only find exact words.
User types "affordable laptop for coding." Your database has "Developer Workstation Pro — $899." Zero keyword overlap. Nothing returned.
User types "warm jacket for hiking." You have "Insulated Trail Parka." Nothing.
User uploads a photo of a product they saw in a store. Keyword search doesn't even know what to do with that.
This is how normal people search. They describe what they want in their own words. Keyword search needs them to guess the exact words in your database. The mismatch is constant, and it gets worse with scale.
What Good Search Looks Like
Good search is invisible. You type what you're thinking, you get what you meant.
It understands intent, not just keywords. "Affordable laptop for coding" surfaces budget developer machines even without exact word matches. Semantic search matches meaning, not strings.
It's fast. Every additional second of latency drops conversions by about 7%. Good search returns results in under 200ms.
It handles failure gracefully. Showing related results instead of a blank "no results" page keeps 56% of users engaged. Most implementations don't bother.
Autocomplete actually helps. Autocomplete alone boosts conversions by 24%. Most implementations either skip it or suggest irrelevant completions based on alphabetical order.
Spotify's search understands moods and genres, not just song titles. Pinterest is essentially a search engine with a visual interface. None of these are LIKE '%query%' wrappers.
Why It Stays Broken
If the data is this clear, why doesn't every team fix their search?
It's not a weekend project. Good search in 2026 means semantic understanding, which means embeddings, GPU inference, vector storage, and a pipeline to keep it all in sync. For 1M items, the infrastructure alone runs $740-1,845/month before you write a line of product code.
The maintenance is the real cost. Models get updated. Indexes need rebuilding. Sync logic breaks at 3 AM. Teams underestimate the ongoing tax.
The ROI is hard to sell. "Search users convert at 3x" doesn't cleanly translate to "improving search will 3x conversions." The causality is muddy enough that it never wins the prioritization fight against a new feature or a dashboard redesign.
So search stays in the backlog. The search bar sits there, quietly losing money.
Search Is a Product Surface
The search bar is the only place in your product where users tell you what they want in their own words. Every other interaction is constrained by your UI - buttons you designed, menus you structured, forms you created. Search is where they express raw intent.
A user who searches is telling you exactly what they need. If you give them the right result, they convert. If you give them nothing, they leave.
The companies that figured this out early built their entire products around it. The ones that didn't are still shipping ILIKE '%query%' and wondering why engagement plateaus.
Search isn't a feature. It's the closest thing to a conversation your product has with your users. Treat it like one.
