Since the start of 2026, one question comes up in almost every conversation I have with retailers: "couldn't we just build this AI shopping assistant ourselves?" It often comes from an IT team that has seen a Google demo, or simply from someone on staff who plugged a general-purpose AI model into the product catalog over a weekend with Claude Code or Codex.
It's a fair question, and I'm not neutral here: I lead the marketing team at iAdvize, which has been building its own AI Shopping Assistant for several years now. But I've watched this scenario play out several times in software over the past 2 decades, and in e-commerce in particular. So I think it's worth telling you how the story usually ends.
The same reasons come up in almost every discussion:
None of these reasons is a bad one. And the third one has been really new for a few months now.
Yes. At the end of 2025, we estimated that a small team could get a prototype running in 30 days. Today, a single developer with an AI coding tool gets there in a few days, sometimes in a few hours.
Large retailers often start from a kit supplied by their cloud or AI partner: Gemini Enterprise for Customer Experience from Google (used by Macy's and Michaels), the Agentic Shopping Assistant from AWS (used by Kate Spade), or Claude for Commerce, a free reference architecture published by Anthropic. Since May 2025, Shopify has also given its merchants' developers what they need to build an agent on their own store.
And a build can work. Amazon claims more than 300 million users for Rufus (renamed Alexa for Shopping in May 2026). At Walmart, shoppers who use the Sparky assistant spend 35% more per order. Building a first version has become easy, and I won't pretend otherwise.
But what happens once that first version is live?
Almost every key building block of an e-commerce site has followed the same process: merchants build their own solution in-house when the technology is new, then come back to a vendor once the cost of maintenance becomes unsustainable.
Site search in the 2010s is the clearest example. Many merchants built their own engine on open-source technology, and it worked. Then the catalog doubled, it had to be rolled out in new languages, and the people who had built it left. Above all, vendor solutions moved much faster than the in-house one, which was already hard to maintain. Most merchants then switched to a specialist (Algolia, Coveo, Doofinder). Who still builds their own search engine today?
Product recommendations followed the same path between 2015 and 2020: the first version worked well, but keeping it relevant as the catalog and traffic changed wore teams out. Same story for first-generation chatbots, which many brands maintained by hand for 2 years before moving to a vendor. And before all that came CRM: companies first built their own customer databases, then adopted a product they could configure to fit them.
Each time, the first version was never the problem. The trouble came at version 3 or 4, once the scope had grown and the original team had moved on.
The AI shopping assistant is very likely to follow the same path, and faster. Because this time, the AI model (the LLM) is no longer the hard part. 2 years ago, it was a rare and expensive component. Today, any developer can use an excellent model for a few cents, and prices keep falling.
So the quality of an assistant depends on everything around the model: a clean, well-structured catalog, business rules (promotions, stock, margins), how the assistant engages visitors on the site, and how performance is measured. Shopify found that AI search on a well-structured catalog converts 2 times better than on data scraped directly from the site. The effort has shifted to data and day-to-day operations.
In practice, once the first version is live, you still have to:
This work takes several quarters, before you even try to keep up with the frantic pace of innovation. A first version is a project. A full deployment is a product that someone has to run for years.
One last point explains why building looks free: it draws on a budget that has already been approved. The developer's salary is already paid, the cloud contract already signed. For a CTO, building costs nothing extra on paper, even when the real cost over 2 years exceeds that of a vendor solution.
Fnac Darty, a leading French electronics and home appliance retailer, had built its own assistant on OpenAI. After a while, the team was 6 to 8 months behind the market, had no analysis of its conversations, and nobody available to close the gap. The retailer then chose iAdvize, and told the story itself in a webinar on April 29, 2026.
This is not an isolated case. An MIT study shows that AI projects run with a specialist vendor reach production 2 times more often than those built in-house. It covers AI projects in general, not just shopping assistants, but the trend is clear.
Amazon, Zalando and Booking still build their own search and recommendations. For them, it's the core business, and they have the teams to run it for years. If that's your situation, building makes sense.
For everyone else, the IT team's skills are not in question. Your team can probably build this assistant. That's THE question to ask: is this where you want them to spend the next 3 years, rather than on your own roadmap?
Before deciding, I'd suggest answering 4 questions honestly:
Then put a number on the hours those answers represent. If the total is small, build. If not, you have your answer.
Some retailers decide to test their assistant against a vendor's, on a share of their traffic. It's a very good idea, on one condition: agree on the metric before you start the test, and pick the metric the business cares about, which is the impact on sales.
On automation rate alone, a simple in-house assistant can look as good as a specialist solution, because answering a question is the easy part. On conversion or revenue, the gap shows up (or it doesn't, which is useful information too).
If you want to go further, here are two resources:
Yves Le Grouyer, CMO at iAdvize