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 ranges, based on what this kind of build actually involves:
| Scope | Typical cost | Timeline |
|---|---|---|
| AI feature added to existing app | $15,000–$40,000 | 6–12 weeks |
| AI shopping MVP (cart, basic AI, one AI feature done well) | $40,000–$90,000 | 16–24 weeks |
| Full AI shopping platform (multi-store, prediction, recommendations) | $90,000–$200,000+ | 24–40 weeks |
A note on these numbers: 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.
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.
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.