# How to turn an AI-built prototype from Lovable, Bolt or Cursor into a real app

> An AI-built prototype is a working spec, not always a shippable app. Here is how a developer audits it, what usually needs rebuilding, and how to get a web prototype into the App Store.

Published 2026-11-02 by ODEL.

A prototype built with Lovable, Bolt, Cursor or a similar AI tool is a good start: it proves the screens and the flow you want. To become a real product it usually needs a review of data security, payments, error handling and store requirements, and for the App Store it needs native features, not only a website in a shell. Some prototypes can be finished; others are faster to rebuild using the prototype as the spec. A developer can tell you which in a short code review.

## What an AI-built prototype is good at

- **Showing the idea.** You can click through it. That beats any written brief.
- **Fixing the scope.** It forces decisions about screens, fields and flows.
- **Testing demand.** You can put it in front of real users before paying for a full build.

Many developers treat a vibe-coded app as an interactive spec rather than a finished codebase. That is not an insult: a clear spec is one of the most valuable things you can hand a developer. See [how to write an app brief](/blog/how-to-write-an-app-brief).

## What usually needs work

These are the areas a developer checks first. Not every prototype has every problem.

| Area | Typical issue in a prototype | What "real" looks like |
|---|---|---|
| Data access | Database rules left open, so one user can read another's data (for example Supabase row level security not enabled) | Every table has access rules, tested with two accounts |
| Secrets | API keys in front-end code | Keys on the server, rotated if they were exposed |
| Auth | Sign-up works, but reset, email change and deletion do not | Full account lifecycle, including in-app account deletion |
| Payments | A checkout button with no webhook handling | Access granted and removed based on payment status |
| Errors | Blank screens when something fails | Error states, retries, error tracking |
| Structure | One huge file, duplicated logic | Code another developer can change safely |
| Tests and builds | None | A repeatable build and basic tests on the core flow |
| Privacy | No policy, unknown SDK data collection | Privacy policy, store privacy forms filled in accurately |

## Finish it or rebuild it?

A developer can usually decide after reading the code and running it.

**Finish it** when:

- the stack is mainstream (React, TypeScript, a standard database),
- the data model makes sense,
- problems are local: missing rules, missing states, a few bad files.

**Rebuild, using the prototype as the spec**, when:

- the data model is wrong for the product,
- every screen has its own copy of the logic,
- you need a native mobile app and the prototype is a web app built only for desktop.

Rebuild does not mean starting from zero. The screens, copy, flows and decisions in the prototype carry over. Ask for a written recommendation with reasons, not a gut call.

## Getting a web prototype into the App Store

Most AI app builders produce web apps. You have three routes to the stores:

1. **Wrap it.** Put the web app inside a native shell with Capacitor, a native runtime for web apps ([Capacitor docs](https://capacitorjs.com/docs)), or a React Native webview. This is fastest, but Apple's guideline 4.2 rejects apps that do not offer more than a website, and Apple lists web clippings and link collections among common rejection reasons ([Apple, App Review](https://developer.apple.com/distribute/app-review/)). A wrapped app needs real native value: in-app purchase, notifications, widgets, offline use, Home Screen shortcuts.
2. **Rebuild the UI natively** in React Native with Expo or in SwiftUI, reusing the backend and logic. More work, better result on phones. See [native vs React Native vs Flutter](/blog/native-vs-react-native-vs-flutter-for-your-first-app).
3. **Stay on the web** as a progressive web app if you do not need store distribution yet.

Whichever route, the store rules apply: digital purchases inside the app go through Apple's in-app purchase (guideline 3.1.1), apps with accounts must offer account deletion (5.1.1(v)) ([Apple, App Review Guidelines](https://developer.apple.com/app-store/review/guidelines/)), and Google requires an in-app path and a web link for account deletion ([Google](https://support.google.com/googleplay/android-developer/answer/13327111?hl=en)). Both stores require privacy disclosures that cover every SDK ([Apple](https://developer.apple.com/app-store/app-privacy-details/), [Google](https://support.google.com/googleplay/android-developer/answer/10787469?hl=en)). See [why Apple rejects apps](/blog/why-apple-rejects-apps-and-how-to-avoid-it).

## A practical handoff checklist

Before you hire someone to finish your prototype, gather:

1. Access to the code repository (export from the AI tool to GitHub if it supports it).
2. Access to the database and hosting accounts (Supabase, Vercel, Firebase or similar), under your email.
3. A list of every third-party service with its API keys, so they can be rotated.
4. A short note on what works, what does not, and what you changed by hand.
5. Your target: web only, App Store, Google Play, or all three.
6. Your Apple and Google developer accounts, or a plan to create them. See [setting up developer accounts for your company](/blog/set-up-apple-and-google-developer-accounts-for-your-company).

## A real example of a web UI inside a native app

[ChairBook](/work/chairbook), ODEL's appointment app for independent stylists, uses a React and Vite web interface hosted inside an Expo and React Native native shell. It ships on the App Store with native pieces that make it more than a website: StoreKit subscriptions, notifications, Home Screen quick actions, in-app review prompts and over-the-air updates. It is listed in [43 store languages](/app/chairbook). The same approach works for many AI-built web prototypes, as long as the native features are real.

## When ODEL fits, and when it does not

ODEL fits if you have a Lovable, Bolt, Cursor or hand-built prototype and want it reviewed, made secure and published to the App Store or Google Play under your own accounts: see [app rescue and maintenance](/services/app-rescue-and-maintenance) and [MVP development](/services/mvp-development). You get a written finish-or-rebuild recommendation and a quote after a discovery call.

A better option might be:

- **Keep iterating with the AI tool** if you are still changing the idea every week; code review is wasted on a moving target.
- **A no-code platform** if the product is mostly forms and tables and does not need the stores.
- **A larger agency** if the prototype is for a regulated field such as banking or health records that needs certified vendors.

If you have a prototype link and a repository, [send them over](/services#start).