How We Built an AI Shopping Assistant (What Works, What's Hard, What It Costs)
How to build an AI-powered shopping app — price prediction, multi-store carts, and OpenAI integration, from the team that built Mebag.
Everyone's building AI into products right now. Most of it is a chatbot bolted onto an existing app and called "AI-powered."
We built something different. Mebag is an AI-powered universal shopping cart — you save products from any online store, the AI tracks prices and predicts when they'll drop, and you can check out across multiple retailers from one place. It's live on Google Play, built on OpenAI, with real users.
I want to walk through how we actually built it — because there's a big gap between "we added an AI feature" and "AI is genuinely doing the work." If you're thinking about building an AI shopping product, or any AI product really, here's what I learned.
What an AI shopping assistant actually does
The phrase "AI shopping assistant" covers a lot of ground, so let me be specific about what Mebag does, because the architecture follows from the actual job.
Mebag lets you save products from anywhere on the web into one universal cart. The AI then does three things that a normal shopping app can't:
It watches prices across stores and predicts when a price is likely to drop, based on historical patterns. It surfaces personalised recommendations based on what you've saved and how you shop. And it pulls everything into a single checkout experience so you're not juggling ten browser tabs and ten accounts.
The "AI" part isn't decoration. The price prediction and the recommendations are genuinely powered by models doing analysis a rule-based system couldn't do well. That's the bar I'd set for calling something AI-powered: is the AI doing something that would be genuinely hard or impossible without it? If yes, it's an AI product. If you could replace it with a few if-statements, it's marketing.
The architecture: where AI fits in a real product
Here's the thing most people get wrong about AI products. They think the AI is the product. It isn't. The AI is one component in a system that's mostly… normal software.
For Mebag, the stack is a Node.js backend, a React frontend, and PostgreSQL for data. Standard, boring, reliable choices. The OpenAI integration is one layer in that system, not the whole thing.
The reason this matters: people get seduced by the AI and underbuild everything around it. But your AI product still needs solid authentication, a real database, proper API design, error handling, and all the unglamorous infrastructure that every product needs. The AI sits on top of that foundation. If the foundation is weak, the AI doesn't save you.
When we built Mebag, probably 70% of the engineering was the normal product — accounts, the cart system, the data model, the store integrations, the checkout flow. The AI layer was maybe 30%. And that 30% only worked because the 70% underneath it was solid.
The hard parts nobody warns you about
AI costs scale fast, and they sneak up on you
Here's a number that surprises every founder I talk to. OpenAI API calls are cheap individually and expensive in aggregate.
Say a single AI operation costs you a fraction of a cent. Feels free. Now multiply it by every product every user saves, every price check, every recommendation refresh, running continuously across your whole user base. Suddenly you have a real monthly bill that grows directly with usage — which means the more successful you are, the more it costs you.
We designed cost control into Mebag from the start because we'd seen this catch people out. You cache aggressively — if you've already analysed a price pattern, don't pay to analyse it again an hour later. You batch operations where timing allows. You pick the right model for each task — you don't use your most expensive model for a job a cheaper one handles fine. And you monitor spend in real time so you see a cost spike the day it happens, not at the end of the month.
AI cost management is an engineering discipline. Most teams learn it the expensive way. Build it in from day one.
Hallucination is a real product risk
Language models make confident mistakes. In a chatbot, that's an annoyance. In a product where a user is making a buying decision based on what the AI tells them, it's a liability.
If your AI says "this price will drop next week" and it doesn't, you've burned trust. If it confidently recommends something irrelevant, the user stops trusting the recommendations. So you build guardrails — validation layers that sanity-check AI output before it reaches the user, fallback logic for when confidence is low, and UX that's honest about uncertainty rather than presenting every AI guess as fact.
The honest framing matters. "We predict this is likely to drop based on past patterns" is a true and useful statement. "This will definitely drop" is a lie your AI will eventually tell. Design the product to make claims it can actually back up.
The data is the hard part, not the AI
Everyone focuses on the model. But the model is the easy part — you call an API. The hard part is getting good data into it.
For price prediction, you need price history. Gathering that, cleaning it, storing it, keeping it current across many stores — that's the real engineering. The AI is only as good as the data you feed it. We spent far more time on the data pipeline than on the AI integration itself. That's normal. That's where the work actually is.
What it costs to build an AI shopping product
Honest framing, based on what this kind of build actually involves:
| Scope | What drives the cost | Timeline |
|---|---|---|
| AI feature added to existing app | One model integration, existing product surface | 6–12 weeks |
| AI shopping MVP (cart, basic AI, one AI feature done well) | New product build plus one well-scoped AI feature | 16–24 weeks |
| Full AI shopping platform (multi-store, prediction, recommendations) | Multiple AI features, multi-store integrations, prediction pipeline | 24–40 weeks |
A note on the real cost: the AI API costs are operational costs on top of the build cost. You pay to build it, then you pay OpenAI (or Anthropic, or whoever) every month based on usage. Factor both into your model. A cheap build with runaway API costs is not actually cheap. We'll walk through both sides — build and ongoing model usage — on a scoping call.
When AI is the right call (and when it's hype)
I say this as someone who builds AI products: most products don't need AI, and adding it because it's trendy makes them worse.
AI is the right call when it does something genuinely hard without it — analysing patterns in large amounts of data, generating content, understanding natural language, making predictions from history. Mebag's price prediction is a real AI use case because predicting price movements from patterns is genuinely hard to do with rules.
AI is hype when you're adding a chatbot nobody asked for, when a few business rules would do the same job more reliably and cheaper, or when the AI introduces unpredictability into something that needs to be predictable. Not everything benefits from a probabilistic answer. Some things need to be exactly right every time, and for those, AI is the wrong tool.
The question I ask every client who wants to "add AI": what specific job is the AI doing, and would a non-AI solution do it better? If they can't answer the first part clearly, they're not ready to build an AI product — they're chasing a buzzword. I'll tell them that, even though we're the ones who'd build it.
What I'd tell someone building AI today
Build the boring foundation first. Auth, database, API, error handling. The AI sits on top of solid software. Weak foundation, and the AI can't save you.
Design cost control from day one. AI costs scale with success. Cache, batch, pick the right model, monitor spend. Learning this after your bill explodes is the expensive way.
Be honest about what the AI can and can't do. Hallucination is real. Build validation, build fallbacks, and design UX that's truthful about uncertainty. Trust is the whole game.
And pick the AI use case carefully. The best AI products use AI for the thing AI is genuinely good at, and use normal software for everything else. Mebag works because the AI does the prediction and the recommendation — the genuinely hard parts — and reliable boring code does everything else.
Mebag's checkout orchestration layer has processed transactions across multiple retailers without requiring users to manage separate sessions, and price alerts are delivered within minutes of a price change being detected. Read the full case study →
Muhammad Nabeel is the co-founder of Teamseven. We built Mebag — an AI-powered universal shopping cart, live on Google Play, built on OpenAI. If you're building an AI product and want to talk to people who've actually shipped one, reach out.
FAQ
What does it cost to build an AI shopping assistant? It scales with scope — a focused first version, a fuller product, and a large multi-feature AI platform sit at very different points on the range, and we'll only give you a real number once we know which one you're building. The build cost is only part of the picture — ongoing model usage is a real operating expense that scales with how successful the product becomes.
Why do AI running costs surprise founders? Because individual API calls are cheap and aggregate usage is not. A fraction of a cent per operation feels free until you multiply it by every product every user saves, every price check and every recommendation refresh, continuously across your user base. The bill grows directly with usage, so success increases cost.
How do you control AI costs in production? Four things, built in from day one: cache aggressively so you never pay twice to analyse the same thing, batch operations where timing allows, pick the right model for each task rather than using your most expensive one everywhere, and monitor spend in real time so a cost spike is visible the day it happens rather than at month end.
Where should AI actually sit in a product's architecture? Around a deterministic core, not in place of it. The reliable parts of the product should stay ordinary code, with AI handling the genuinely fuzzy work. That boundary decision is the most important architectural call in an AI product, and it's made before anyone writes a prompt.
When is AI the right call, and when is it hype? AI earns its place when the task is genuinely fuzzy — understanding intent, summarising, matching on meaning rather than keywords. When the task has a correct answer computable by ordinary logic, ordinary logic is cheaper, faster and more reliable. Using a model there adds cost and uncertainty for nothing.
