DoorDash's new AI chatbot, called Ask DoorDash, lets you type what you want in plain words and get a cart instead of scrolling through restaurant menus yourself. According to TechCrunch's report, it also takes photos as input, so you can show it a dish instead of describing it.
The headline is the feature. The interesting part is what it signals: typing what you want, in your own language, is quietly becoming the default way people expect to use any app with a catalog. That shift matters more to a small builder in Colombo than it does to DoorDash.
🔍 What "Ask DoorDash" actually changes
The old flow was a funnel you walked manually: open the app, pick a category, open a restaurant, read the menu, add items, repeat. Ask DoorDash collapses that into one input box. You describe intent ("cheap rice and curry near me, no beef") and the system does the browsing.
That is conversational commerce: the interface is a sentence, not a navigation tree. Two things make it work, and neither is exotic anymore.
| Capability | What it replaces | What it needs |
|---|---|---|
| Plain-language search | Category filters + manual browsing | Embeddings over your catalog |
| Photo input | Typing a description you don't have words for | A multimodal model |
| Cart assembly | Tapping each item by hand | Structured tool-calls back into your app |
Key takeaway: The feature isn't "a chatbot." It's intent in, structured result out. The chat box is just the skin over a catalog you already have.
💡 Why this is a bigger deal for small teams than for DoorDash
DoorDash has millions of users and a search team. For them this is an incremental upgrade. For a two-person shop running a grocery app, a tuition-class booking site, or a parts catalog, the same pattern is the difference between a customer finding the thing and bouncing.
Here's the asymmetry I keep coming back to:
- Big platforms had good search already. Conversational search saves their users a few taps.
- Small catalogs usually have bad search: an exact-match text box that returns nothing if you misspell "thosai" or search in Sinhala. For them, semantic search is not a luxury, it fixes a broken experience.
So the lesson isn't "we should all build a chatbot because DoorDash did." It's that the cheapest version of this, semantic search over your own listings, now clears the most common reason people fail to buy.
A customer who types "school shoes black size 8" and gets zero results because your DB only matches the word "footwear" is a customer you lost to bad search, not to price.
🛠️ How you'd build the cheap version yourself
You do not need DoorDash's budget. The minimum viable version of this is three steps, and the first two are a weekend's work for one engineer.
- Embed your catalog. Run every product title and description through an embedding model once, store the vectors. A few thousand items costs cents.
- Embed the query at runtime, find the nearest catalog vectors, return those. That alone gives you "search in your own words," no chat UI required.
- (Optional) Add a chat layer that turns the matches into a sentence and assembles a cart via tool-calls. This is where cost and complexity climb.
Steps 1 and 2 are retrieval. Step 3 is an agent. The jump in price between them is real, and it's worth knowing the number before you commit. You can sketch it on our AI chatbot cost calculator, and if you go further and let the model take actions like building a cart, the AI agent cost calculator will show how tool-calling rounds inflate the bill.
| Version | What it does | Rough complexity |
|---|---|---|
| Retrieval only | "Search in plain words" returns matching items | Low — one embedding model, one vector lookup |
| Retrieval + summary | Returns items and a one-line explanation | Medium — adds a generation call per query |
| Full agent | Understands intent, assembles a cart, takes actions | High — multi-step, multimodal, error handling |
My honest advice for most local apps: ship step 2, measure whether people use it, and only build step 3 if usage justifies the running cost.
🌐 The Sri Lanka and multilingual angle
The part of this that English-language coverage tends to skip: semantic search is one of the few AI features that helps more in a multilingual market, not less.
A keyword search box punishes the user for not knowing your exact catalog wording. In Sri Lanka, that means it punishes anyone who types in Singlish, switches between Sinhala and English mid-sentence, or spells a food name the way they say it rather than the way you stored it. Embedding-based search closes a lot of that gap automatically, because it matches on meaning, not characters.
- "kottu near pita kotuwa" should find Kotahena kottu listings even if none contain the exact string.
- A photo of a string-hopper dish should find string hoppers even if the user has no idea it's called idiyappam on your menu.
This is the same capability DoorDash is shipping, applied to a problem global tools rarely bother to solve well: messy, mixed-language, locally-spelled queries.
Bottom line: The smaller and more multilingual your audience, the bigger the relative win from conversational search. DoorDash gets a nice-to-have. You might get the feature that finally makes your search usable.
🚀 What this means for you
DoorDash didn't invent anything you can't copy in spirit. They put a sentence-shaped interface on a catalog and let a model do the browsing. The reusable idea, not the brand feature, is the takeaway.
- If your app has a list of anything people search, your real competitor is exact-match search returning nothing.
- The cheap win is retrieval, not a chatbot. Embed your catalog, match on meaning, ship that first.
- Add the conversational and photo layers only when you've seen demand and run the cost numbers so the bill doesn't surprise you.
- In a Sinhala-English market, semantic search isn't a flourish. It's the fix for a search box that has been quietly failing your users all along.
The news is that a giant shipped it. The opportunity is that the same pattern is now within reach of a solo builder on a learning budget.
