AI can build your app, but it cannot tell you if anyone will use it.

By
Sofia Olavides
Updated onJuly 14, 2026
The barrier to shipping a product has never been lower. With the right prompts and an AI coding tool, a founder with no engineering background can have a working app in an afternoon. No developer needed. No design system. No user research. Just an idea, a few iterations, and something that technically functions.
It is also creating a UX debt problem at a scale we have not seen before.
vibe coding
ˈvīb-ˌkō-diŋ
noun
writing computer code in a somewhat careless fashion, with AI assistance.
- Merriam-Webster, Slang & Trending
Vibe coding solves the technical problem of product creation however it does not solve the human problem.
An AI tool can generate a checkout flow but it cannot tell you that the reason your users abandon the payment screen because they do not trust the interface. It can build a dashboard but it cannot reveal that the metrics you chose to display are not the ones your users need to make decisions. It can produce something that works. It cannot tell you whether it works for the people you built it for.
A product that functions and a product that fits are not the same thing. That gap is where UX debt lives.
UX debt is not new. It has always been the accumulation of unresolved design problems, unvalidated assumptions, and unmet user needs that compound quietly until they cannot be ignored. Like financial debt, it does not disappear. It accrues interest.
What is new is the speed at which it is being created. When building was slow and expensive, teams were forced to be deliberate. Now that a working prototype takes hours, the pressure to skip research and testing has intensified. Why spend two weeks on user interviews when you can have something live by Friday?
Because your users are comparing your Friday launch to products built with years of research behind them. The bar has not moved just because the tools have changed.
The most visible cost is the redesign. A product launches, metrics look acceptable, the team moves on. Then, slowly, the signals appear. Support tickets climb. Users churn at the same point in the flow. Conversion flatlines. What looked fine at launch was quietly losing customers all along. By the time the redesign happens, it costs far more than the research that was skipped. That is before accounting for the revenue lost in the interim.
The less visible cost is building the wrong thing entirely. A team launches a fitness app on the clear assumption that users want to track distance and calories. No research to validate this. Post-launch, they discover their audience cares more about social features - sharing progress, joining challenges, getting peer feedback. The product fails not because it was poorly built, but because it was built for a user that did not exist. With AI tools, this mistake now takes an afternoon to make instead of six months. But it still takes months to undo.
Neither team was careless. Both were moving fast without a method for knowing where to slow down.
Some teams treat iteration as a substitute for research. Ship, observe, adjust. Why plan when you can react?
Iteration without research is expensive guessing. You can move fast in the wrong direction. You can optimise a flow that should not exist. You can build ten versions of a product that nobody wanted in the first place.
Research changes what you build, not just how you build it. User interviews and usability testing done before design begins surface needs the team did not know existed. They expose assumptions that were never questioned. When development starts (whether by a developer or an AI) the team executes on evidence, not instinct.
In the UAE and across the Middle East, this matters more than in most markets. User expectations here are shaped by global exposure, cultural context, and a bar for digital experience set by both world-class government services and global platforms. An interface built on generic assumptions will not land. The user in Dubai is not the default user. It is a pattern we encounter consistently in our research work across the region: teams who built confidently for a user they had never actually spoken to.
The answer is not to slow down. It is to front-load the thinking.
Research before design is the highest leverage point. It does not need to take long. A round of user interviews before the first prompt is written will shape everything that follows. Usability testing on a prototype (even one generated in an hour) will catch critical issues before they become embedded assumptions. The goal is not to make building slower. It is to make the expensive mistakes cheap.
The teams that build the best AI-assisted products are not the ones who prompt the hardest. They are the ones who understand their users well enough to know what to build in the first place. This is exactly where we work with product teams at DOT - not after the UX debt has accumulated, but before the first decision is made.
Make research a shared input, not a design team deliverable. When product managers, founders, and engineers understand what users actually need, every prompt they write is better informed. UX debt accumulates fastest in organisations where research lives in one team and building lives in another.
UX debt is not a design problem. It is a business problem. It shows up as churn, lost conversion, expensive rebuilds, and products that never find their market.
The irony of vibe coding is that the speed it promises often evaporates in the rework it creates. Shipping in a day is fast. Rebuilding three months later because users never adopted the product is not.
AI has made it possible to build anything. Research is what ensures you build the right thing. In a market as demanding as this one, that distinction determines everything.
The tools have changed but the users have not. Making the digital feel human still takes the same thing it always did: actually understanding people.