Opinion
How do AI-generated apps compare to apps made by humans?
September 22, 2026
When I first wrote this post in 2023, the AI app builders were tools like Appy Pie, and the honest answer was "they're a novelty, a human team wins every time." That answer is now wrong, or at least it's the wrong question.
In Y Combinator's Winter 2025 batch, a quarter of startups had codebases that were 95% or more AI-generated. The tools doing this (Lovable, Base44, Bolt.new, v0, Cursor, Replit, FlutterFlow) build working software. I've watched a non-technical founder produce a usable prototype over a weekend that would have taken a contractor a fortnight in 2023.
Whether AI can build an app is settled. The question founders bring us now is the gap between an app an AI generated and an app you can put in front of paying users without it falling over, and that gap is what this post is about.
Updated 22 September 2026. I rewrote two parts of the June version. I'd said a wrapped web app gets rejected by Apple on the first attempt, and this year's first-hand accounts from founders don't support that. I'd also quoted some security figures that didn't match their sources. Both are corrected below, and the prices now match what we offer.
Three different things hide under that phrase, and they fail in different ways.
No-code platforms (Bubble, Glide, Adalo) let you assemble an app visually. You don't see code, and in Bubble's case you can't export any. AI code generators (Lovable, Base44, Bolt.new, v0) write real source from a prompt, usually React, Vite and Tailwind on the web side. AI-assisted coding (Cursor, Claude Code, Copilot) speeds up a developer who already knows what they're doing.
The first two are what people mean by "vibe coding" (describe the app, get a working build), and they're what most of our enquiries are about. FlutterFlow sits slightly apart: it's visual like no-code, but it exports real Flutter and Dart code you can take elsewhere.
We recommend these tools. For the right job they're the fastest way to learn something true about your idea.
You can test whether anyone wants the thing before you spend real money, which used to be the most expensive part. A clickable, working prototype built over a weekend costs far less than paying someone else to build a proof of concept. And when you've built the prototype yourself, you understand your own product better and brief a development team far more clearly.
If you're at the "is this idea any good" stage, a vibe-coded MVP is often the correct move. The trouble starts when that MVP succeeds and you try to grow it.
Veracode's 2025 GenAI Code Security Report tested more than 100 models on 80 coding tasks, and 45% of the code they produced failed its security tests. Log injection and cross-site scripting were the weakest areas, each failing in more than 85% of the relevant tasks. CodeRabbit's December 2025 study of 470 open source pull requests found AI-written changes carried about 1.7 times as many issues as human ones and were 2.74 times more likely to introduce cross-site scripting flaws. BaxBench, a benchmark built at ETH Zurich, found that 62% of the backend code written by even the best model it tested was either incorrect or had a security vulnerability.
Live apps look no better. In October 2025 the security firm Escape.tech scanned more than 5,600 publicly deployed apps built on Lovable, Base44, Bolt.new and similar platforms, and found over 2,000 vulnerabilities, more than 400 exposed secrets and 175 instances of personal data such as medical records and bank details. Tenzai had five AI coding agents (Claude Code, OpenAI Codex, Cursor, Replit and Devin) build the same three apps in December 2025 and found 69 vulnerabilities across the 15 results, several rated critical.
AI is good at producing something that runs, and that's a different target from something safe to run. The model optimises for "does the demo work", not "what happens when someone hostile pokes at the login endpoint". Gartner expects prompt-to-app development by citizen developers to increase software defects by 2,500% by 2028.
In the apps themselves, the gaps usually open up after launch. Most AI builders set up sensible access rules for the tables they create at the start. On a Supabase-backed app (most Lovable apps, and many built with Bolt.new or Cursor), the key in the browser is meant to be public, and it's only safe while row level security is switched on and written correctly for every table, including the one you added three weeks in. Business rules are the other gap. If the only thing stopping someone booking without a verified email is an instruction in the AI's prompt, it won't always be followed, so the rules that matter need to run in code on the server.
Wrapped web apps do get approved, including ones built on Lovable and Base44. In the first-hand accounts we read from founders who submitted AI-built apps this year, rejections came far more often from in-app purchase set-up (Guidelines 3.1.1 and 3.1.3(b)), account deletion and sign-in (5.1.1(v)), design and iPad layouts, and trademarked names than from the app being "just a website".
Guideline 4.2 still applies. It says an app "should include features, content, and UI that elevate it beyond a repackaged website", and Apple occasionally rejects a wrapped app as too thin. We've read of it happening to a Capacitor-wrapped Lovable app that already had Face ID and push notifications, so bolting on one native feature won't guarantee approval, even though rejections like that are rare.
Payments cause far more trouble. In UK App Store apps, Guideline 3.1.1 requires in-app purchase for subscriptions, premium content and paid features, so a Stripe checkout for digital content inside the app gets rejected. Some storefronts, including the US, let apps link out to a web checkout, and selling real-world services such as bookings doesn't need in-app purchase at all. An app sold on the web and in the stores usually ends up with two payment systems that both have to update the same customer record. Some builders make this harder: as of September 2026 there's no way to connect Apple or Google in-app purchases inside Base44's own wrapper. (Our App Store Fees in 2026 explainer covers how the fees work, and our Base44 to production page covers the payment routes.)
Google Play works differently. Its webview rule is aimed at apps that wrap sites the developer doesn't own, so it doesn't apply to your own web app, though its minimum functionality policy still does. The bigger hurdle is testing: personal developer accounts created after 13 November 2023 need at least 12 testers opted in for 14 days in a row before the app can go to production.
Apple's Guideline 5.2.1 says "Apps should be submitted by the person or legal entity that owns or has licensed the intellectual property and other relevant rights." We submit from your own Apple and Google accounts, you keep the owner role, and our first-submission approval rate is 90% across both stores.
Other limits are quieter. Wrapped web apps struggle with background work such as background location, device features like Bluetooth need native plugin code, and heavy web apps chew through memory on older Android phones. Bubble back-ends behind a native frontend can burn through Workload Units fast once traffic arrives.
My 2023 answer set this up as a choice, and it isn't one. AI gets the app built quickly, and people make it hold up once customers depend on it.
The expensive mistake is picking a route before anyone has looked at the app. Some founders pay for a full rebuild they didn't need. Others wrap an app whose payments were never going to work inside a wrapper. A wrapper built with a tool such as Capacitor is fine for plenty of apps. A rebuild in React Native with Expo, or in Flutter, makes sense when the wrapper keeps getting in the way: payments that have to work across the web and both stores, offline use, background tasks, or device features it can't reach cleanly.
What's worth keeping depends on what you built on, which is why we never quote a rebuild blind. About four in ten projects we see need only partial migration, not a full rebuild.
FlutterFlow projects are in good shape. On its paid plans FlutterFlow exports a real Flutter project, so a team can refactor the architecture, replace FlutterFlow's helper code, move state management to BLoC or Riverpod and extend it natively. Once you edit the export there's no way back into the FlutterFlow editor.
Lovable, Base44 and Bolt.new apps are usually React web apps with Vite and Tailwind (Bolt.new can also start an Expo mobile project). Many can reach the stores in a wrapper around the app you already have. Base44 will even build the store files for you, though its wrapper can't take in-app payments yet. If you do need a rebuild, the screens are rebuilt in React Native or Flutter, and your business logic, APIs and Supabase or Firebase setup usually carry across. We've moved a Lovable app's backend off Lovable Cloud onto the founder's own infrastructure, and our Lovable to production page covers that move and the routes to the stores.
Bubble exports no code, so the practical path is to treat its database and workflows as an API behind a new frontend, moving the heaviest calls onto a thin Supabase or Firebase layer to fix the unit economics.
Before any of that, start with a free check. Tell us about your app through a short form, and a person reads it and replies in writing with what we'd look at first. If it's worth going further, a £95 review covers what an automated scan can't judge: whether you can charge for the app, whether your business rules hold, whether search engines and AI assistants can find it, and what you own. The £95 is credited in full against any paid work we do next.
Getting an existing AI-built app to production is then a fixed £999 to £1,999, depending on complexity. That covers fixes, security, moving your backend, in-app payments, store submission, or a wrapper route. A full native or cross-platform rebuild isn't in that band, and if you need one we give you a fixed-price quote after the review. That's our Vibe Code to Production service. After a delivery, the first month of App Care is included and the onboarding fee is waived. App Care has a three-month initial term, so months two and three are billed at the plan rate. It covers what breaks after launch: new iOS and Android releases, SDK and target API deadlines, and store policy changes.
So, how do AI-generated apps compare to apps made by humans? In 2026, AI can build the first version. Making it safe to charge customers for still takes people who've done it before.
Often, yes. Wrapped web apps built on Lovable, Base44 and similar tools do get approved. Most rejections we've read about come from in-app purchase set-up, design and iPad layouts, trademarked names and sign-in, not from the app being a website. Apple can still reject a thin app under Guideline 4.2, so it has to be useful as an app. If you sell digital content or subscriptions, a UK App Store app needs Apple's in-app purchase. When a wrapper keeps getting in the way, a rebuild in React Native or Flutter can reuse your business logic, APIs and backend.
On its own, usually not. Veracode found 45% of AI-generated code failed its security tests, and Escape.tech found more than 2,000 vulnerabilities and more than 400 exposed secrets across more than 5,600 live apps built on vibe-coding platforms. AI optimises for code that runs, and safety is a separate target. It's a strong starting point, but it needs a security and architecture review before real users and real data go near it.
It depends on the platform, what you charge for and how you plan to grow. FlutterFlow exports carry forward well. Lovable and Base44 apps can often reach the stores in a wrapper, unless payments or device features get in the way. Bubble apps usually need a new frontend against the existing data. About four in ten projects we see need only partial migration, not a full rebuild. Our £95 review settles it before you spend on either, and it's credited in full against the work.
With us, getting an existing AI-built app to production is a fixed £999 to £1,999, depending on complexity. That covers fixes, security, moving your backend, in-app payments, store submission or a wrapper route. A full native or cross-platform rebuild isn't in that band. We quote a fixed price for it after the £95 review, which is credited in full against whichever work you go ahead with.
Often no, and many apps don't need to go native at all. FlutterFlow exports real Dart that can be refactored and extended. Lovable, Bolt.new and Base44 apps keep their business logic, API code and Supabase or Firebase integrations, and it's mainly the screens that are rebuilt. Bubble is the exception, since it exports no code, but even there your data model and workflows can stay in place behind a new frontend.
Written by Gareth Reese, Founder and CTO of Foresight Mobile. Gareth has been involved in mobile app development for over 25 years and has led delivery at Foresight since 2017, including maintenance of flutter_markdown_plus, downloaded about 570,000 times a month on pub.dev.
Ready to take your prototype to production? Get a free check or read about Vibe Code to Production.
