From a restaurant-only name lookup to a platform-wide item discovery engine — redesigning search across UX, backend, and navigation over two years.
Before the evolution work began, Bolt Food's search had a fundamental scope problem. It could only find restaurants — by name, or loosely by cuisine tag. If you wanted a "tofu green curry," you couldn't search for that dish and discover who served it. You had to already know the restaurant.
This was a critical gap in a product where discovery drives conversion. Users who couldn't find what they were looking for left without ordering. The investigation revealed poor relevance, bad tag logic, unhelpful zero-result states, and a navigation structure that made search harder to reach over time.
Search wasn't just a feature gap. It was the primary way users discovered food — and it only showed them restaurants they already knew.
The 2023 investigation documented the problems with concrete examples. The core issues fell into three categories:
Search was structurally limited to restaurants. There was no way to search for a dish, ingredient, or specific item across the city's providers. A user searching for "tofu" saw restaurant names that happened to contain the word — not the restaurants that actually served tofu dishes. This wasn't a quality problem, it was a capability gap that required a new feature entirely: item search.
Item search was the most significant capability addition to the search experience. Before it launched, search was a restaurant finder. After, it became a food discovery tool — enabling users to query by dish name or ingredient and see results across every provider in the city, regardless of whether they'd heard of those restaurants before.
The results page introduced a new pattern: dish cards, not restaurant cards. Each result showed the food item itself — photo, name, price — with the provider name as supporting context rather than the headline. This was a deliberate inversion of the existing search mental model, where the restaurant was always the primary unit of navigation.
A search for "burger" would previously return a list of restaurants with burger in their name or tags. With item search, it returns individual burger dishes from every provider in the city, each with its own direct add-to-basket path. The user journey shortens: search → dish → basket, without necessarily visiting the provider menu screen at all.
Item search introduced a tabbed results interface: an Items tab for dish-level results, and a Restaurants tab for the existing provider-level results. This gave users explicit control over what kind of answer they were looking for, without forcing a single result type on all queries.
The two tabs also had different sorting logic. Item results sorted by relevance and availability, with the provider's distance as a tiebreaker. Restaurant results preserved the existing ranking logic. The tab selection persisted within a session — users who preferred item results wouldn't have to re-select on every search.
Technically, item search required a fundamentally different backend approach. Provider search loaded results per user location — a bounded, manageable dataset. Item search needed to query every dish in every active provider's menu across the entire city simultaneously, then rank and deduplicate the results.
This was solved through a city-wide search index — a separate data model that maintained an up-to-date catalogue of all menu items available in a city at any given moment, indexed for text search. The city-wide search service was extended to carry navigation context, ensuring item results were always surfaced within the correct screen rather than leaking across different app sections.
A search for "tofu green curry" can now surface merchants you never previously saw, but that serve your favourite Thai dish — that's a genuinely new type of discovery.
Alongside item search, a parallel track addressed search quality problems that had been documented since 2023. These weren't visible UX changes — they were backend and logic fixes that changed what happened when you typed something in the search bar.
The algorithm had been matching search queries against all language translations of every category tag — including Azerbaijani, Estonian, and Georgian translations of tags that were irrelevant to the user's market. This caused nonsensical results like "Fish" appearing for a search for "Salad." The fix scoped tag matching to the relevant locale context.
Search previously required near-exact lexical matching. "Hesburger" with an accidental space, or "Burger" with a typo, could return zero results. Misspelling tolerance and whitespace handling reduced sessions with zero search results by 5%, generating an additional €250k in annualised ICP from users who would previously have hit a dead end and left.
A zero-result search page previously showed nothing — no guidance, no suggestion, no way forward. The redesigned empty state includes a clear message explaining the result, and a direct button back to the home screen. A simple change that stopped zero-result searches from being session-enders.
The old ranking logic could surface closed or unavailable restaurants ahead of open ones if the name match was stronger. Availability was introduced as a higher-weight ranking signal, so results that a user could actually act on appeared first.
Filters existed before the evolution work — users could technically filter by discount, rating, delivery fee, and cuisine tags. But there were two problems: the filter UI wasn't prominent enough to drive consistent usage, and the underlying tag quality was so poor that filtered results were often wrong or empty.
The filter work ran on two parallel tracks. On the UX side, filter chips were repositioned to appear immediately below the search input — always visible before a query, not hidden behind a secondary tap. This meant users encountered filtering as part of the search flow rather than discovering it after getting unsatisfactory results.
On the backend side, tag allocation was audited and a tagging guidelines framework was established. The previous system allowed local ops teams to tag providers with any label, which created both quality problems (irrelevant tags) and the "KFC hack" scenario where misleading aliases produced confusing results. The new framework established a unified tag hierarchy and allocation rules applied consistently across markets.
When item search launched, filters needed to work across both result types. Filtering by "Vegan" on the Items tab should surface vegan dishes; the same filter on the Restaurants tab should surface vegan-tagged providers. The filter state persisted when switching between tabs, so a filtered query didn't require re-applying filters after changing result type.
The bottom navigation restructure was the most strategically complex part of the search evolution, because it required removing an existing entry point while simultaneously ensuring search remained accessible everywhere.
The context: bottom navigation supports a maximum of 5 tabs. As new tabs were added — most notably a dedicated Restaurants tab — something had to give. The decision was to remove the Search tab from the bottom navigation.
The decision was grounded in a prior A/B test that had specifically measured whether having search in both the home page and the bottom navigation made a meaningful difference to search usage or outcomes. The result: removing search from the bottom nav did not produce a visible drop in performance, because users who wanted to search found the search bar on the home screen.
The new tabs structure introduced a dedicated Restaurants tab — a filtered view of food providers, separate from the broader home screen that also included groceries, retail, and DineOut. This made the navigation more semantically clear: Home is everything, Restaurants is food specifically.
Underpinning the navigation restructure was a new configurable tabs system — a backend-driven architecture that allowed the tab setup (entries, order, icons, translations) to be configured without a client release. Previously, the navigation structure was hardcoded. Making it configurable meant the team could run A/B tests on tab compositions, roll out market-specific navigation setups, and iterate on the navigation structure without waiting for an app release cycle.
First standalone search screen redesign. Added "Recently ordered from" providers to the search screen idle state — reducing the need to navigate away from search to find a familiar provider.
Significant amount of users abandoned the home screen without scrolling or interacting. Hypothesis: some could be converted if there was a prominent search input. Moving search to top of Home reduced exit rate and increased first interaction with the discovery surface.
Comprehensive audit of search quality failures — tag translation matching bugs, availability ranking issues, ZZ locale hacks. This investigation became the roadmap for the 2024–2025 work. Also the first articulation of item search as a planned capability.
Structured plan for all discovery tools — search, home categories, banners, shortcuts, and navigation tabs. City-wide item search formally scoped for Q2. Configurable tabs architecture designed to support future navigation changes without client releases.
City-wide dish-level search. Results tabs (Items / Restaurants). New dish card result format. +0.6% session→order conversion, −11.2% merchants viewed before ordering, €1.4m annualised ICP. Mentioned in company all-hands and Summer Summit as a game-changer for discovery.
Fuzzy matching for misspellings and whitespace. 5% reduction in zero-result sessions, €250k additional ICP. Zero-result dead end replaced with home screen recovery CTA.
Personalised ranking of item search results using ML. Delayed by hiring in Q3–Q4 2025, testing began Q1 2026. Alongside: fuzzy search (handling phonetic variants and more complex misspellings) in parallel development.