What we've learned from reviewing over 20 AI-built apps

You built your app with AI and it works, whether people are using it day to day or you're demoing it to win over potential customers and investors. That's a real achievement, and it's further than most tech founders with an idea ever get. But if you're honest, there's probably a question at the back of your mind that you can't quite answer: what is actually going on under the hood, and will it hold up when your users, your data and your ambitions start to grow?

At Elemental we've been designing and building web, mobile and software products since 2005, and over the past couple of years more and more of the founders who come to us arrive with an app (partially or fully) built mostly or entirely with AI. We've now reviewed well over 20 of them, and not one has come back with a clean audit. In some cases the fixes were modest and quick to make, while in others there was so much wrong that the honest advice was to start again on proper foundations.

Below we share what we keep finding, two real stories from founders we've worked with, and how we decide whether an app can be fixed. It isn't an argument against building with AI; it's about knowing what you actually have before your users, an investor or a 2AM outage find out for you.

Vibe coding is a good way to start

We're genuinely positive about what AI has made possible for non-technical founders. A few years ago, turning an idea into something people could click through meant raising money or finding a technical co-founder first. Now you can build a working version yourself, put it in front of potential users, gather real feedback, refine the idea and show investors something tangible rather than a slide deck.

As a proof of concept (POC) or prototype, that's hugely valuable, and the founders who do it have usually proved something important: that people want what they're building.

Where we see problems is when that prototype quietly becomes the production platform. Building software that stays secure and stable as users grow, and can take on new features for years, is a different job from getting features working. It draws on years of engineering experience that most founders understandably don't have, and the AI doesn't fill that gap as well as it appears to.

Why "it works" isn't the same as "it's ready"

The tricky thing about AI-written code is that it looks good. It's tidy, well laid out and plausible, so anyone reviewing it, including the AI itself, tends to skim over it and assume it's fine. In our experience the mistakes in it are much the same ones a junior developer makes; they just hide better, because the code around them looks so professional.

The same goes for how many of these apps look. On the surface they're impressive, with clean screens, tidy spacing and what feels like a polished user experience. Look more closely, though, and many of them look remarkably alike, and once you work carefully through what each type of user actually needs to do, it's common to find crucial steps missing or journeys that simply don't make sense. AI is very good at making a strong first impression, but a product that takes people smoothly from start to finish needs careful thought about who is using it and why.

AI tools are also very good at doing exactly what they're asked and very quiet about what they skipped along the way. If you ask for a sign-up page, you'll get one that works when someone signs up normally. Whether it copes with the person who abandons halfway, signs up twice or has their payment declined depends on whether anyone thought to ask, and a founder without an engineering background usually wouldn't know to.

None of this shows up in a demo or with your first few hundred users, which is why the problems tend to surface later, when the data piles up or a larger customer starts asking questions, and they're harder and more expensive to put right.

What we find again and again

Every AI-built app is different, but the same handful of problems come up in almost every review we do.

• Data that's organised for today, not for growth. The way an app and its database stores its information is one of the hardest things to change later, and it's often set up in a way that works fine with a few hundred records but slows the whole platform down once you have hundreds of thousands. Your users experience this as pages that take longer and longer to load, long before anything actually breaks.
• Only the happy path is catered for. Real people go back a step, lose their connection or take a route through the app nobody planned for. We call these exceptions, and great apps handle them well because the whole process was planned in advance, with someone thinking through what could go differently at every step. AI tools usually miss them, and when exceptions haven't been designed for, users end up stuck or unable to finish what they came to do, and they rarely tell you; they just leave.
• Nothing to catch things when they fail. Payments get declined, emails don't send and outside services (APIs) go down for an hour. Well-built software expects this and recovers gracefully, while many AI-built apps simply stop, leaving users in limbo and you with no clear idea of what happened.
• Gaps in how users' data is protected. These are usually invisible from the outside, which is exactly why they matter. Customers' personal information can be far easier to get at than a founder realises, and it's the kind of problem you'd much rather find in a review than hear about from a customer, an investor or a regulator.

Tech founders are often surprised by how normal everything seemed before we looked under the hood. These issues don't announce themselves, so the only way to find them is to go looking for them on purpose.

Two founders, two very different outcomes

The AI-built app we could put on solid foundations

An early-stage founder came to us with a fairly simple web app that had been built with AI. She had no background in tech or coding, but she knew her industry and the problem she was solving extremely well. She'd become frustrated with her current development provider, who kept missing deadlines and was hard to get hold of, and she had no real way of knowing how well the platform had been built or how it would hold up once real users arrived.

We started with a full audit and found genuine concerns: the code was poorly structured, and parts of the database had been designed in a way that would make the platform noticeably slower as more data was stored. To her relief, none of this meant starting again. The foundations were good enough to work with, so we fixed the issues, made some improvements to the user experience (UX) along the way and launched the platform. It's still running smoothly today, we continue to support it and we’re add new features all the time. 

The "almost finished" app that couldn't be finished

A non-technical founder had someone build him a fairly complex web app for schools and learners, using AI. When he came to us it was described as almost complete, but every demo followed the same pattern: things that had been broken were now fixed, and something new had broken somewhere else. The user experience looked reasonable at first glance, but once we spent proper time going through the journeys of each type of user (there were quite a few), many of the flows simply didn't make sense or lacked proper logic to guide the user in a user-friendly manner.

He wanted it finished quickly and felt that he and his developer were going round in circles on a last 20% that never got done, so he asked us to finish it off. We agreed to look first, cautiously, because fixes that break unrelated parts of an app usually point to deeper problems (red flags!). Once our developers had access to the code and the database, they found the architecture was so poor that there was no realistic way to get the platform to a finished, dependable state. We could have patched individual problems, but we don't recommend that, because it only delays the same conversation and costs more in the meantime.

So we told him honestly, and it wasn't an easy conversation, since it meant setting aside the time and money he'd already put in. We started again from the beginning, mapping out every type of user, their journeys and what each one needed to do, then designing and building a lean first version MVP  with room to add the features planned for later. The point was to give him a product he can keep building on with confidence, rather than one he's afraid to touch.

Fix or rebuild: how we decide

Whether an AI-created app can be fixed or needs rebuilding is the question tech founders worry about most, and the real answer is that we can't say until we've looked at it properly. It depends on how the code is structured, how the data is organised and how well the screens and user journeys work, and an app that looks polished can be fragile underneath while a rough-looking one turns out to be perfectly workable and very stable.

That's why we always start with a full, in-depth audit before recommending anything. Depending on the size and complexity of the app, it normally takes between one and two weeks. At the end of it you get a clear picture of what's sound, what needs fixing and in what order, and, where it applies, an honest view of what can be saved and what needs redoing.

As the two stories show, the answer can go either way. What we've learned is that the expensive outcome is rarely the rebuild itself; it's the months spent patching something that was never going to hold up, before anyone looked at the foundations.
 

Where to start

You don't need a full audit to get a sense of where your app stands. We've turned the questions we ask in every review into a free five-minute assessment called Is your AI-built app safe to scale? You answer 16 quick yes, no or not sure questions, with no technical knowledge needed, and get an instant score across four areas: how ready your app is for growth, how well your users' data is protected, what would happen if something broke, and how easily someone else could work on your code.

You'll also get a personalised report showing what to look at first, and one of our team will be in touch to talk it through, having looked at your app beforehand.

You've already done the hardest part by building something that solves a real problem and that people want. Finding out now whether it's safe to scale, while your product is still small and changes are cheaper, is far easier than finding out after something has gone wrong.